May 2, 2006 at 1:35 pm
So a month ago I got a call saying my data was screwed up on an import. so I went in and sure enough the fields were mapped inncorrectly. Kind of strange I thought since I did not change this DTS but I questioned myself. So I just got the same phone call and again the mapping issue is back. I corrected it and now the data is good. Is there a particular issue that this mapping problem could come up again like that? If so how to get around it?
May 3, 2006 at 6:49 am
I have faced the same problem in DDQ a couple of times. The column names and parameters get mismatched on their own. DTS is haunted
May 3, 2006 at 7:09 am
I have experienced a similar situation.
May 3, 2006 at 7:47 am
Thats just spooky. Well maybe I will change the Name. Maybe it is crazy like that
May 3, 2006 at 8:07 am
Is it a result of adding/removing fields in a table, view, or view dependency (table) that is used by the DTS?
May 3, 2006 at 9:23 am
No literally it was a working process. I have not touched the process for months
May 3, 2006 at 9:28 am
Not the process (DTS)... the database
May 3, 2006 at 9:46 am
I do updates to the database but the tables involved have not been touched. Not to make a conspiracy theory but I am pushing data from SQL 2K to SQL 2k5
May 3, 2006 at 9:48 am
Wait I am sorry I am pulling from Navision odbc to SQL 2k. The transformation from 2k to 2k5 is working properly. Not really a big deal. i was just curious if there was an easy answer
May 3, 2006 at 12:24 pm
OK...must be the "NAVISION" thing! We're getting ready to do a Navision upgrade and I'm worried that it's going to break custom reports we already have published.
We've also experienced a few wierd things with DTS packages. In migrating DTS packages I've re-mapped to the servers, I've saved them, then run them only to find they never saved the new mapping and were still pointing to the old server!
Has anyone experienced this with SQL2005?
May 3, 2006 at 5:24 pm
If you're running the DTS package as a scheduled job, make sure you're referencing the package guid and not the version guid. It sounds like an older version of the DTS is being executed or saved over the newest version. Your current version could also revert to an older version if there has been a restore of the msdb database, since that's where DTS package objects are actually stored.
As for changing the information in a connection, I have had cases where I then also have to reselect my source and destinations in my transformations to completely commit the change.
I've been using SQL Server 2000 DTS for quite awhile and don't recall issues of mappings redoing themselves, only if you edit the source or destination and get that pop-up that asks if you want to redo the mappings.
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply