I deployed a Microsoft sql server 2008R2 with sample data.
Installed report builder 3.0, visual studio 2008.
These all installed on a windows server 2008 enterprise.
I successfully created Cube from ssas and used it for deploying report.
Now, my next task is make this process automatically.
I am thinking is that possible to tell the ssis to do the following
Creating a new cube base on the latest sql data and use current date for its name. This will do it daily.
Or
Copy the current cube and rename it. Use the same cube building information for a new cube.
Note that I also thinking is that possible to use linux bash script to rename the cube before ssis scheduled task kick-in. so this way can skip one step on above method.
The reason behind that is because of the high up want to have the cube created daily and so they can check them and keep a record for those data.
Any suggestion are welcome as I am a newbie on ssas cube thing and so my thought may not be on tge right track.
I think it can be done. But it is hard to meet your requirement with existing build-in component in SSIS, an alternative is to use script task to build .net code and create the XMLA and tsql script to process the logic you needs. Consider you're new to all that thing, I will not recommend you to do that. But it do works.
Hope it can help you!
Related
As a company we have grown and we are now moving a couple of SQL Server 2016 databases over to a new server. We have SSIS packages that run off the databases that we are moving from server 1 to server 2.
Is there a way to easily identify using SSMS which SSIS packages use the current server and databases we are moving? Some of the old SSIS packages don't have documentation so we are trying to avoid physically opening up all the SSIS packages. We would prefer to identify the SSIS packages that are impacted.
Thank you!
Here are my solutions on the top of my head. I'm not an expert by any means so don't be surprised if someone comes up with something better.
In SSMS, you can view the data sources being utilized by a
package by... Object Explorer > SQL Server Agent > Jobs > (Your Job) > Steps > Edit... > Data Sources (Tab)
Here, you can view the data sources of your package. This is
slightly faster than opening all your SSIS packages; but, it isn't a
great solution either.
Conversely, recognize that .dtsx files are simply plain text
files. You can scan keywords within all of them using a number of
different scripts (PowerShell, Python, SSIS package w/ a Script
Task, etc.)
What you can use depends on the tech stack that your organization
supports but I imagining Googling for such a program/script would
not be difficult.
If you are utilizing SQL Server configurations in your packages
and you consistently do so for every package, you can query the
[SSIS_Configurations].[dbo].[SSIS Configurations]
NOTE: Solution (1) and (2) do not take configurations into account.
Hopefully, some of these solutions are helpful to you. I would be interested in an efficient means to do this without delving into scripts as well.
I have searched and have not found an answer for my following question:
I am running an SSIS package created from the Export data task for a database, in SSMS jobs. I want to add month and year to the file name when it is created but don't have access to Visual Studio. How would I do this in the Job Step Properties? Or would I need to do it on the SSIS package creation?
I could create a .bat file that could update the file name after the completion of the job but I would rather have it all done in one go.
Thanks.
SQL 2008 R2
--NO Visual Studio--
There is no way to do this using the Export Data Wizard. You would need to edit the SSIS package to do this.
Technically you could do this without Visual Studio, since an SSIS package is just a text file, but you would really have to know what you are doing. I wouldn't want to try it.
You're allowed to run Powershell scripts as job steps. Roughly the same as your .BAT file idea, but you could at least have it run in-line, manage it within the Job Agent, etc.
I would need to migrate a SQL database from Sybase to MS SQL Server. Before doing the actual migration on the production server I first created an SSIS-package with SQL Server Management Studio's Import/Export Wizard for testing with other databases. The test migration was successful and I would now like to deploy my SSIS-package to the real servers.
However, it seems I cannot simply run the package in Management Studio choosing different data sources for it - it only runs on the same databases for which it was created. Now, it can be edited in something called SQL Server Business Intelligence Development Studio (or BIDS for short)(I am using the SQL Server 2008 version), but going through every data flow task changing the destination source manually for each of the ~ 150 tables I am moving is ineffective and also introduces a possibility for error.
I there a way to quickly change what data source is to be used for ALL destination sources in ALL the flow tasks of an SSIS-package? If not, what simple method is there for testing migration with test databases first and simply changing the data sources when deploying?
I am using ODBC data sources, but for some the package shows OLE-sources in BIDS instead.
I hope I was clear enough. If you have additional questions, please ask! Thank you!
I would use a variable for the ConnectionString property of the connection manager. A package level configuration can be very useful for accomplishing this task. Several ways to do this. I prefer to use a table in SQL Server that holds all the configurations for all packages. This can be especially effective if you have multiple packages and need to dynamically change a set of connection managers across those multiple packages.
The basic steps are:
Opposite click on your SSIS design surface and select "Package Configurations..."
Create a package level configuration of Configuration Type "SQL Server"
Store your connection in a Configuration table in SQL Server
Alter your Connection Manager to use a variable for the ConnectionString Property
Populate that variable from the Configuration table via your package level configuration
When it comes time to switch from Test to Production, simply update the connection string in your configuration table
These screenshots can help...
This is part of a larger package management framework that I implemented using this book:
Microsoft SQL Server 2008 Integration Services: Problem, Design, Solution
I highly recommend it. Should take less than a day to set it up. Book has step by step instructions.
This question and its associated answers also helpful.
I'm looking for the best approach (or a couple of good ones to choose from) for extracting from a Progress database (v10.2b). The eventual target will be SQL Server (v2008). I say "eventual target", because I don't necessarily have to connect directly to Progress from within SQL Server, i.e. I'm not averse to extracting from Progress to a text file, and then importing that into SQL Server.
My research on approaches came up with scenarios that don't match mine;
Migrating an entire Progress DB to SQL Server
Exporting entire tables from Progress to SQL Server
Using Progress-specific tools, something to which I do not have access
I am able to connect to Progress using ODBC, and have written some queries from within Visual Studio (v2010). I've also done a bit of custom programming against the Progress database, building a simple web interface to prove out a few things.
So, my requirement is to use ODBC, and build a routine that runs a specific query on a daily basis daily. The results of this query will then be imported into a SQL Server database. Thanks in advance for your help.
Update
After some additional research, I did find that a Linked Server is what I'm looking for. Some notes for others working with SQL Server Express;
If it's SQL Server Express that you are working with, you may not see a program on your desktop or in the Start Menu for DTS. I found DTSWizard.exe nested in my SQL Server Program Files (for me, C:\Program Files (x86)\Microsoft SQL Server\100\DTS\Binn), and was able to simply create a shortcut.
Also, because I'm using the SQL Express version of SQL Server, I wasn't able to save the Package I'd created. So, after creating the Package and running it once, I simply re-ran the package, and saved off my SQL for use in teh future.
Bit of a late answer, but in case anyone else was looking to do this...
You can use linked server, but you will find that the performance won't be as good as directly connecting via the ODBC drivers, also the translation of the data types may mean that you cannot access some tables. The linked server might be handy though for exploring the data.
If you use SSIS with the ODBC drivers (you will have to use ADO.NET data sources) then this will perform the most efficiently, and as well you should get more accurate data types (remember that the data types within progress can change dynamically).
If you have to extract a lot of tables, I would look at BIML to help you achieve this. BIML (Business Intelligence Markup Language) can help you create dynamically many SSIS packages on the fly which can be called from a master package. This master package can then be scheduled or run ad-hoc and so can any of the child packages as needed.
Can you connect to the Progress DB using OLE? If so, you could use SQL Server Linked Server to bypass the need for extracting to a file which would then be loaded into SQL Server. Alternately, you could extract to Excel and then import from Excel to SQL Server.
Fellow Developers I have been working on creating a Database with SQL Server 2005, now I finished that step, its a huge and massive one. Now the company wants me to export their data from their Access 2007 db to this sql 2005 database I created.
I know that I will be using field mapping, but is it actually possible to do that ?
Any Suggestion ?
A major portion of my job is converting data from one data source into another. I am actually doing a Filemaker Pro to SQL Server conversion right now. I have tried some of these Automatic solutions and they are hit or miss depending upon the complexity of the data involved. Usually, I do it by mostly by hand writing scripts (I do automate some of the scripts using a VB6 application I created many years ago).
I have found that doing the scripts by hand always produces the best conversions.
This fellow describes how he did it. There is a tool called "SQL Server Migration Assistant (SSMA) for Access" that you can download from Microsoft. The blog also has a Word document that you can download for a step-by-step description of what to do.
You can download SSMA here and possibly just figure out how to do it without searching further.
It depends on the complexity of the import. Try using SQL's import wizard first. If that's too limited, you may need to create an SSIS package.