beercat2
asked on
Question About DTS
Hi everyone! This is probably a simple question, but I'm a beginner using DTS.
I have a VB application that executes a DTS package when a button is pressed. Yesterday, while at one of our satellite offices, I tested the program from one workstation and it worked fine, but when I tried it from another I received an error (which I unfortunately forgot to write down). The error was something vague - something about a "Multi-step OLE DB process failed to execute". On the 2nd workstation, I even attempted to just execute the DTS package straight from SQL Enterprise Manager and still received the error, so I'm thinking that it doesn't have anything to do with the VB application.
Can anyone tell me if a client machine uses any particular DLL's when attempting to execute a DTS package on a server? Any ideas what may cause this?
Thanks,
Brian
I have a VB application that executes a DTS package when a button is pressed. Yesterday, while at one of our satellite offices, I tested the program from one workstation and it worked fine, but when I tried it from another I received an error (which I unfortunately forgot to write down). The error was something vague - something about a "Multi-step OLE DB process failed to execute". On the 2nd workstation, I even attempted to just execute the DTS package straight from SQL Enterprise Manager and still received the error, so I'm thinking that it doesn't have anything to do with the VB application.
Can anyone tell me if a client machine uses any particular DLL's when attempting to execute a DTS package on a server? Any ideas what may cause this?
Thanks,
Brian
ASKER
Thanks spcmnspff.
I discovered the "local scope" issue you are referring to while developing the app. There is 1 file involved, a CSV file, but the user selects the file with my app, so the path and filename are local to the machine where the app is running. And I know it works on some workstations which have the same drives mapped as others where the app doesn't work.
I will be back in the satellite office tomorrow and will investigate the files listed on the link you sent me. Thanks for your help - I'll let you know if this fixes it.
I discovered the "local scope" issue you are referring to while developing the app. There is 1 file involved, a CSV file, but the user selects the file with my app, so the path and filename are local to the machine where the app is running. And I know it works on some workstations which have the same drives mapped as others where the app doesn't work.
I will be back in the satellite office tomorrow and will investigate the files listed on the link you sent me. Thanks for your help - I'll let you know if this fixes it.
ASKER
No luck. Both machines have all of the files listed on the SQLDTS.com website. The problem occurs even if I'm working in Enterprise Manager and I remove everything except the first step - which is a simple SQL statement (a DELETE statement) - from the package. I still get the error.
"Multiple-step OLE DB operation generated errors. Check each OLE DB status value, if available. No work was done."
Any more ideas?
"Multiple-step OLE DB operation generated errors. Check each OLE DB status value, if available. No work was done."
Any more ideas?
ASKER
Could this be an MDAC issue?
ASKER
Well, this was an MDAC issue. If you create a DTS package on a machine with an older version of MDAC, it can't be run from a client machine with a newer version.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
http://www.sqldts.com/main.asp?nav=1,6,225,0
Although, it sounds to like there might be some resources that aren't available at the client that were at the server when the package was created. Bear in mind that when executing the package at the server any references to files, network shares, etc need to be located on the server i.e. c:\ refers to \\mysqlserver\c$\ etc. And when executed on the client (even from enterprise manager) all the resourcces are searched for locally i.e. c:\ now refers to \\localclient\c$\ . This "local scope" issue can get in the way when attempting to redistribute your package and execute it anywhere other than the server. The best way around it is to use the UNC paths (as I did in my examples). This way any references to network resources are universal and absolute.