Running SSIS fails on local server, not remotely
-
I have a very simple SQL Server 2008 R2 SSIS package that imports 4 .csv files into a table.
If I deploy the SSIS package to the remote SQL server and run it interactively from SSMS on my client machine, the package runs fine.
If I run that exact same SSIS package from SSMS on the actual SQL server, it fails with data conversion errors "Output Column [ColumnName] failed because truncation would occur...." on all columns in the .csv file. Scheduling the SSIS package raises the same data conversion errors.
I am logged in as the same user on both machines, and the location of the .csv files is the same (on the SQL server).
Does anyone know of something that would cause a single SSIS package to fail when executed locally on the SQL server, but NOT when executed remotely? I could have expected permissions errors, but data conversion errors? Any help would be appreciated!
-
Chi Chi Cabron (7/5/2012)
I have a very simple SQL Server 2008 R2 SSIS package that imports 4 .csv files into a table.If I deploy the SSIS package to the remote SQL server and run it interactively from SSMS on my client machine, the package runs fine.
If I run that exact same SSIS package from SSMS on the actual SQL server, it fails with data conversion errors "Output Column [ColumnName] failed because truncation would occur...." on all columns in the .csv file. Scheduling the SSIS package raises the same data conversion errors.
I am logged in as the same user on both machines, and the location of the .csv files is the same (on the SQL server).
Does anyone know of something that would cause a single SSIS package to fail when executed locally on the SQL server, but NOT when executed remotely? I could have expected permissions errors, but data conversion errors? Any help would be appreciated!
In both cases destination database and table remain same ?
--rhythmk
------------------------------------------------------------------
To post your question use below link
https://www.sqlservercentral.com/articles/forum-etiquette-how-to-post-datacode-on-a-forum-to-get-the-best-help
🙂 -
Rick Krueger (7/5/2012)
I've seen that error when the text qualifier gets modified. Check out this blog post from @JamieT.That did it, thanks!
-
Chi Chi Cabron (7/6/2012)
Rick Krueger (7/5/2012)
I've seen that error when the text qualifier gets modified. Check out this blog post from @JamieT.That did it, thanks!
Great !! But could you please post your findings and solution.
--rhythmk
------------------------------------------------------------------
To post your question use below link
https://www.sqlservercentral.com/articles/forum-etiquette-how-to-post-datacode-on-a-forum-to-get-the-best-help
🙂 -
rhythmk (7/9/2012)
Chi Chi Cabron (7/6/2012)
Rick Krueger (7/5/2012)
I've seen that error when the text qualifier gets modified. Check out this blog post from @JamieT.That did it, thanks!
Great !! But could you please post your findings and solution.
I went to the post at http://sqlblog.com/blogs/jamie_thomson/archive/2010/11/25/sql-server-2008-sp1-cu-6-includes-small-changes-to-dtsx-files.aspx
This article states that the text qualifier property in the dtsx file pre-CU6 is read as ' " ' (double quotes), but post-CU6 it is read as "_x0022_".
Examples from the article:
Pre-CU6: <DTS:Property DTS:Name="TextQualifier" xml:space="preserve">"</DTS:Property>
Post-CU6: <DTS:Property DTS:Name="TextQualifier" xml:space="preserve">_x0022_</DTS:Property>
I checked the dtsx file I was running and, sure enough, the text qualifier character was "_x0022_". Checked the version of SQL Server on my local machine and it was completely up to date. Checked the version on the remote server and it was at CU 4 (d'oh!). So the server didn't know how to interpret the "_x0022_" text qualifier and was failing, but my client, being up-to-date, interpreted it correctly and worked. Or at least that's my interpretation.
Changing the text qualifier to " (double quotes) in the dtsx package allowed it to run on the server (CU4), but it would fail when I tried to run from my local client.
So I updated the SQL server (which should have been done, anyway) and now everything works as it should.
Like the blog post says:
There is of course a simple but important lesson here – make sure your developer workstations are running the same builds as your DEV, Test, UAT and Production boxes. Its the sort of problem that you should only encounter once because you’ll never make this stupid mistake twice. Right?
-
wow i could never guess that could be the issue! it helped me, thanks for sharing the link!
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply