Question

I am having troubles where a data flow task is completing and the table is being loaded but all of the character fields are empty. The sad thing is all run perfectly during development and testing. But there are environment differences between dev and prod, dev is fully 32 bit and prod was just set up and is 64 bit.

So the scenario is I built the system on an XP machine using 32 bit SSIS with a SQL Server 2000 back end (I'm working for a not for profit at the moment, it was all they had). The source is a firebird data base. I have deployed to prod and that is where all of the date and number data is transferred just not the character data.

Prod is running Windows 2008 64 bit to SQL Server 2008 R2 64 bit. We installed the 32 bit Firebird ODB driver, set up the firebird service and they are all working fine. In the debug menu I have set Run 64 bit runtime to false. I checked all of the advanced edit items under both the source and destination tasks and there appears to me to be no problems there, DT_WSTR and NVARCHAR. I've done a preview in both source and destination and in the source the missing data is all displaying fine. All I changed between the prod and the dev environments are the connection configurations, by hand by opening them up and changing the ODBC source for the source and the SQL Server for the dest. I took the Dev data base off line to make sure there were not problems related to poor connection config changes. So running in debug mode there is a row being created in SQL for each row in firebird, but only the number and date fields are being populated, the character (all nvarchar to match firebird) are failing to populated.

Where have I missed something, this is my first 32 bit to 64 bit conversion and I don't know if it was as simple as building the manifest and then deploying the package after changing it's connection configs and deploying to MSDB.

Thanks for any help. Mark

Was it helpful?

Solution

Poking around I found this

http://www.sqlservercentral.com/Forums/Topic1254262-364-2.aspx

(which I was involved in - I'm the can of beans)

Which says to change the redirect property of the column to redirect row, then pick it up again and merge it back in.

Which makes absolutely no sense, but apperently worked for at least two people.

Perhaps if this fixes the issue you could provide a more detailed analysis of how it fixes it.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top