Global Variable gone missing
-
Hi All
Just wanted to sound out the group to see if anyone has coem across a problem that came up recently.
We have 30 something DTS packages that copy individual tables from a Progress database via ODBC. The first thing that each of these packages do, is run an ExecuteSQL task to get a row count from the Progress table it's copying. This count is then stored in a global variable which is used later to verify the copy was successful.
We used to get the row count from the local SQL table prior to the copy because it's much quicker. However, recent process changes have required us to perform the record count directly against the Progress database.
Since this change there have been isolated instances where the global variable mapping on the parameters dialog has gone missing. The ExecuteSQL task runs successfully, but the global variable is set to zero. This causes problems later in the package because it thinks it should be copying zero records.
In three seperate executions of all packages, one package has failed twice with this error. A few others have run successfully one-time, only to fail on the next run.
Any ideas on tracking this problem down would be most appreciated.
--------------------
Colt 45 - the original point and click interface
-
WHat version of SQL and have you condsidered using ActiveScripting to get both the records and the count so they are guaranteed to match up if get the record count based on the data selection?
-
Ooops ... sorry ... SQL 2K sp3a, W2k Server sp4
The ExecuteSQL task is just "SELECT COUNT(field) FROM Table". If you are thinking about discrepancies in the record count, that won't happen, when the copy is running there are no other connections to the Progress Database.
For a single package, this same task works for one execution and failed the next. When I checked the paramete mapping dialog, it had <none> for the global variable.
--------------------
Colt 45 - the original point and click interface -
Is it possible that it's trying to use the variable before it's been set? It's worth checking the workflow thoroughly. I go into disconnected edit for double checking as it's sometimes possible to end up with bogus precedents which causes strange results.
JK
-
Julie
Thanks for your reply, however I don't think this is the case. The ExecuteSQL task that sets the variable is the first step in the package and the variable isn't used until after the datapump task which is the third step.
--------------------
Colt 45 - the original point and click interface
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply