THe package runs fine, data moves over.
HOwever, one of the tables contains what used to be sales dollars from the originating fox pro table which is a currency data type.
the sql table is using a money data type.
what's happening, i finally noticed, is that all negative dollars are being translated into 0 values.
i've tried making the sql table a decimal data type, i've switch the vfpodbc.dll from the June 2003 version to the 1999 version and it's all the same.
when i connect to the fox pro database using the same driver, it shows the negative values in the db. yet when I run (select * from sales where salesamount <0) there are no negative values at all. there either positive or zero.
i'm going to simply scream i'm so freakin frustrated. why the heck in 2003 cant we exchange a simple currency data element from a **MICROSOFT** product to a **MICROSOFT** product.
Sorry for the tone. It's crap like this that adds to project time. I've spent 8 hours now, one whole developer day trying to fix. Of course, Microsoft no longer provides an easily downloadeable driver upgrade. It's missing from there site. So finding the latest fox pro driver is not an easy task.
Trying to download and install MDAC 2.8 says right on the download page that it does not include OLEDB and ODBC drivers any longer. Well what the heck good is that? Great...we get the latest ado or ado.net updates. Whoopee! Retards! You need the drivers to utilize ADO or ADO.NET...HELLO!
sorry again guys, but i'm about to go postal. i just hate this stupid crap. And I hate it when I peruse MS KB and it doesn't come up with crap. never does. have to use google. Perhaps MS should buy out google and replace there search technology to something that actually WORKS.
So, now that i've had my little anit-microsoft tired, is there any one who would be willing to lend any advice about why negative currency values are being translated to 0 values from a foxpro currency type to a microsoft sql decimal or money data type?are you using the SQL 2000 Import/Export tool?
you might need to delve into the 'transform' dialog and do a manual CAST on the field.
I've had to do something broadly similar for the last month because some genius in an [unnamed] government department thinks that my data needs are based on some guy from Ballarat inputting 125000 fieldsby hand. Why the [****] you'd do unnecessary casts or processing in exporting data to go from one SQL Server database to another I really will never, ever know. I guess stupidity never goes out of fashion, but it has to be dealt with.
In your case, some pre-processing may be the thing. going from one platform from another may screw up by default but can be conquered by DTS in the vast majority of cases.
j|||As Atrzx mentioned, you may have to do an ActiveX Script on your transform of that data element. Since it's vbscript, something like
DTSDestination("elem_id") = CCurr(DTSSource("Current Element ID"))
might do the trick.
No comments:
Post a Comment