I had to work on my colleague’s SSIS solution which was developed using SQL Server Integration Services 2005 SP2 version. I could successfully open the SSIS solution but I could not load the package and I got following message.
First I thought, it’s a problem with the configurations or any other dependencies because “Package Configurations” are summoned first as soon as you load/open the package. Then i thought its a problem with the encryption settings of package and checked that one. But I didn’t get a hint. Then I opened the SSIS package’s code view and looked at the XML code bravely. But that was just a stunt 🙂 and I could not find the solution for 5-10 minutes.
Then I thought of googling the solution and found the following link/thread.
Cause described by Microsoft:
This problem occurs because the value of the DateTime variable is saved in string format when you save the SSIS package. However, the string representation of the DateTime variable is based on the date format that is specified in the Windows locale. Therefore, when you try to load the SSIS package on a computer that has an incompatible locale date format, the operation fails.
Please read this article for Microsoft’s detailed explanation & solutions.
But you know what, this also didn’t solve my problem. And finally I found the problem with the package.
My colleague used one of the Dataflow task components i.e. “SharePoint List Adapter“. And the problem was, we both have different versions of “SharePoint List Adapter”. Finally, I installed the same version of SharePoint List Adapter on my machine and voilà. Package got loaded successfully without any errors or warning 🙂
Conclusion…to be noted down:
Just like for SSIS configurations, we (try to … most of the time) simulate UAT/Test/Production environment in our development desk. Like that, we must think/analyze of environment where the SSIS package was developed. And if you see the cause described by Microsoft, you will feel that they are talking pretty much about the same thing i.e. SSIS package has some dependencies of environment.
I am sure most organizations follow best practices of keeping all environments (Development, Test/UAT, Production etc.) similar/equipped enough as far as tools, technologies, dependencies etc. are concerned.
Anyways, I hope this also helps you somewhere.