March 8, 2014 at 9:00 pm
Hi all,
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.
So the scenario is I built the system on an XP machine using 32 bit SSIS with a SQL 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 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.
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 chaning it's connection configs and deploying to MSDB.
Thanks for any help.
Mark
March 10, 2014 at 11:28 am
The debug setting for 64 bit is only for when you are running in debug mode (in visual studio) afaik.
Do you have the 32 bit tools installed on the server?
However, when I've tried to do a 32 bit connection in the 64 bit runtime, it has just error'ed out ... not ignored nvarchar fields. So I'm not sure if this is your issue.
March 10, 2014 at 1:40 pm
I did forget to mention that it was whilst running in debug mode that the problem made itself visible. I changed the connections and then ran a test on one table to check the new connection string.
I'm in the office in just over an hour so I'll try then. I cant play at home as I'm on a 32 bit system at home and the data is sensitive so is not allowed to be taken off site.
Fall back is getting a 32 bit server up and running, admins are in the process of building it but I'd hate to see the same problem happen there. Fingers crossed.
March 11, 2014 at 7:35 pm
Ok it looks like I have a work around solution that came from a previous post that works. I have done a single test and all looks good.
http://qa.sqlservercentral.com/Forums/Topic1254262-364-3.aspx"> http://qa.sqlservercentral.com/Forums/Topic1254262-364-3.aspx
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply