Click here to monitor SSC
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Running SSIS fails on local server, not remotely


Running SSIS fails on local server, not remotely

Author
Message
Chi Chi Cabron
Chi Chi Cabron
SSC Rookie
SSC Rookie (35 reputation)SSC Rookie (35 reputation)SSC Rookie (35 reputation)SSC Rookie (35 reputation)SSC Rookie (35 reputation)SSC Rookie (35 reputation)SSC Rookie (35 reputation)SSC Rookie (35 reputation)

Group: General Forum Members
Points: 35 Visits: 154
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!
Rick Krueger
Rick Krueger
SSC Veteran
SSC Veteran (262 reputation)SSC Veteran (262 reputation)SSC Veteran (262 reputation)SSC Veteran (262 reputation)SSC Veteran (262 reputation)SSC Veteran (262 reputation)SSC Veteran (262 reputation)SSC Veteran (262 reputation)

Group: General Forum Members
Points: 262 Visits: 691
I've seen that error when the text qualifier gets modified. Check out this blog post from @JamieT.



Rick Krueger

Follow @dataogre
rhythmk
rhythmk
Say Hey Kid
Say Hey Kid (662 reputation)Say Hey Kid (662 reputation)Say Hey Kid (662 reputation)Say Hey Kid (662 reputation)Say Hey Kid (662 reputation)Say Hey Kid (662 reputation)Say Hey Kid (662 reputation)Say Hey Kid (662 reputation)

Group: General Forum Members
Points: 662 Visits: 1062
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

http://www.sqlservercentral.com/articles/Best+Practices/61537/
:-)
Chi Chi Cabron
Chi Chi Cabron
SSC Rookie
SSC Rookie (35 reputation)SSC Rookie (35 reputation)SSC Rookie (35 reputation)SSC Rookie (35 reputation)SSC Rookie (35 reputation)SSC Rookie (35 reputation)SSC Rookie (35 reputation)SSC Rookie (35 reputation)

Group: General Forum Members
Points: 35 Visits: 154
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!
rhythmk
rhythmk
Say Hey Kid
Say Hey Kid (662 reputation)Say Hey Kid (662 reputation)Say Hey Kid (662 reputation)Say Hey Kid (662 reputation)Say Hey Kid (662 reputation)Say Hey Kid (662 reputation)Say Hey Kid (662 reputation)Say Hey Kid (662 reputation)

Group: General Forum Members
Points: 662 Visits: 1062
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

http://www.sqlservercentral.com/articles/Best+Practices/61537/
:-)
Chi Chi Cabron
Chi Chi Cabron
SSC Rookie
SSC Rookie (35 reputation)SSC Rookie (35 reputation)SSC Rookie (35 reputation)SSC Rookie (35 reputation)SSC Rookie (35 reputation)SSC Rookie (35 reputation)SSC Rookie (35 reputation)SSC Rookie (35 reputation)

Group: General Forum Members
Points: 35 Visits: 154
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: <DTSTongueroperty DTS:Name="TextQualifier" xml:space="preserve">"</DTSTongueroperty>

Post-CU6: <DTSTongueroperty DTS:Name="TextQualifier" xml:space="preserve">_x0022_</DTSTongueroperty>


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?

boriskey
boriskey
SSC Rookie
SSC Rookie (27 reputation)SSC Rookie (27 reputation)SSC Rookie (27 reputation)SSC Rookie (27 reputation)SSC Rookie (27 reputation)SSC Rookie (27 reputation)SSC Rookie (27 reputation)SSC Rookie (27 reputation)

Group: General Forum Members
Points: 27 Visits: 256
wow i could never guess that could be the issue! it helped me, thanks for sharing the link!
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search