Hello all, Environment: Server Version: SQL Server 2005 (9.0.4053) : SQL_Latin1_General_CP1_CI_AS collation Here’s what I have: A pipe delimited text file. Nothing special here. No unicode. An SSIS package with a data flow task moving the data in this text file into a SQL Server table. Again, nothing special here. No data conversions, simply a text file source connected to an OLDEB destination. Everything at default (let the wizard figure it out). SQL table columns match the text file exactly. SSIS is transforming some of the special characters into values that are incorrect. For example, the value “Gutiérrez” in the text file ends up as “Gutiérrez” in the SQL table. No errors, no warnings are reported back from the SSIS execution I checked the hex code of the character in the text file: E9. Just for reference, this is the hex sequence for that value: 47 75 74 69 E9 72 72 65 7A. Pretty straight forward. I checked the code page of the column in the SSIS data connection (1252). I compared E9 to the corresponding character in the 1252 code page (é). This value is stored in the database correctly in other places. The source for the data in the “other” places is a view that comes out of an external system. So, the database has the capability of storing the character properly. The datatype of the column in the SQL table is varchar(30). So, SSIS has to be the culprit here. Any ideas? I’m going to run this through an explicit data conversion block to see if it fixes it. But, I should not have to do that. Thanks, Greg Wilkerson

I believe your assumption about the source file is wrong. Enable a Data Watcher before the insert and inspect the values. Then try using the UTF8 collation in the Flat File Source. Inspect the values again, is the E9 coming in properly?Arthur My Blog

The hex value for the character in question is E9. No doubts about that. Never heard of Data Watcher; I'll have to find that and see what that buys me. Never thought about UTF8. I'll have to check into that.