I recently saw some forum posts on SSC.com asking if there was a way to bulk import DTS 2000 packages into a SQL 2005 database.
The answer is that you can use the DTSBackup utility available for download at www.sqldts.com. Its a lightweight and extremely useful tool that can save hours of mouseclicking, and it works on both SQL 2000 and 2005.
Amazon Link: SQL Server 2000 Developer Edition
Normally in SSIS when we want to issue a SQL command against each row in a dataflow, we use the OLE DB Command component. When executed against SQL Server the command normally takes the form:-
UPDATE dbo.TableName SET ColumnName1 = ? WHERE ColumnName2 = ?
Where “?” can be mapped to the incoming columns in the order they are written.
However you will find that when you are using this component against an Access database, that this syntax will not work. You will get an error saying:
There is more than one data source column with the name “?”. The data source column names must be unique.
Amazon Link: Microsoft® Office Access™ 2007 Inside Out (Inside Out (Microsoft))
Given the problems inherent in loading excel files with SSIS, I thought it might be useful to share with you some code to get you started on interrogating it’s schema prior to running your Execute SQL control tasks or your dataflows.
This is especially useful for me as it allows me to test column names, worksheet names and datatypes etc prior to attempting to load the data (I have found that users have a tendency to format and rename sheets without realising the impact it has on the import). There are other uses too…
The quick answer to this is that you can’t… at least not in a dataflow. Whilst you can dynamically change environments and databases, the column metadata has to remain the same. It’s therefore fairly limited as to what you can load “on the fly”.
There is a work around however for those of you who wish to be able to create a looping mechanism in a single package with a single task to load the data.
Amazon Link: SQL Server 2000 Fast Answers for DBAs and Developers, Signature Edition
This script might be the best SQL insert generator I’ve seen yet. It’s flexible and deals quite comfortably with the majority of problems a dev can come across when attempting to write one of these. Why re-invent the wheel.
Take a look at the website, there are plenty of neat tips and tricks.
Cheers
Frank
Amazon Link: Microsoft SQL Server 2008 T-SQL Fundamentals (PRO-Developer)
I have a SQL generation package that I am using to create sql files that will later be executed against the production environment. It is necessary to do this for corporate IT policy reasons which I won’t go into, however, suffice to say it isn’t the most efficient way to get new data into the database!
The data is input into Excel by the users and then passed to me the run the SSIS package. This worked fine until recently when one of the Excel spreadsheet I recieved had cells in it that were in excess of 8000 characters wide (containing Legal T&Cs).
Amazon Link: The Rational Guide to Extending SSIS 2005 with Script (Rational Guides)
A quick nugget… If you get this error:
[DTS.Pipeline] Error: component “OLE DB Source” (79) failed the pre-execute phase and returned error code 0xC0010001
Check that your variables are mapped and that they can be read at run time. Similarly if you get the same error code with the description:
Configuration from a parent variable “XXXXX” did not occur because there was no parent variable. Error code: 0xC0010001.
Check that you have spelt and referenced the correct parent variable.
After some prompting, I decided it was about time I posted the solution to my initial post on the subject of metadata driven SSIS.
If you have read part one of this series (or other posts related to replication and sql agent), it will come as no surprise to you to know that I am a big proponent of metadata driven control in SQL Server. Whilst more complex to code, it is infinately easier to manage across environments.
I will add further explanations to this package at a later date, but for now, here is the solution and a very brief summary of what it does.
During a recent data migration from Oracle to SQL Server, I came accross the problem of trying to import Greek encoded strings into our SQL Server database. With the standard character set installed with my Oracle client, all I got was upside down question marks with the odd square and ampersand thrown in for good measure.
I was recently asked if you can only use the msdb.dbo.sysdtslog90 table to log SSIS package execution…
It is possible to log your SSIS execution to a database other than msdb, simply by scripting the sysdtslog90 table from the msdb database, and creating it in a new db.
Then when you configure your SQL Server log provider, use a connection manager that points to the database on which you’ve just created your table.
