DTS Package fails with error - Invalid OLEVERB structure

Question

DTS Package fails with error - Invalid OLEVERB structure

suresh_yaram

SSC Veteran

Points: 267
More actions
August 28, 2006 at 6:56 am

#172328

Dear All,

I have a DTS Package that transfers SQL database objects (Tables & Constraints) from one server to another server using Copy SQL Server Objects Task. I am getting an error as below -
Step Error Source: Microsoft Data Transformation Services (DTS) Package
Step Error Description:Invalid OLEVERB structure
(Microsoft Data Transformation Services (DTS) Package (80040000): Invalid OLEVERB structure
) (Microsoft SQL-DMO (80004005): [SQL-DMO]CreateFile error on '<servername>.<tablename>.DP2'. )
Step Error code: 80040000
Step Error Help File:sqldts80.hlp
Step Error Help Context ID:1100
Please let me know if anybody has any clue to this error. I have several Copy SQL Server Objects Tasks in the same DTS package. The package has been configured to run 2 tasks in parallel at any point of time. Each time the package fails to tranfer different set of SQL objects.
Thanks in advance,
Suresh

Viewing 10 posts - 1 through 9 (of 9 total)

You must be logged in to reply to this topic. Login to reply

Erik Kutzler SSCarpal Tunnel Points: 4287 More actions · Answer 1

Do either of the SQL servers happen to be running under Windows 2003?

Regardless, make sure the "Script File Directory" is valid on the Copy tab of the Copy SQL Server Objects Task properties window.

suresh_yaram SSC Veteran Points: 267 More actions · Answer 2

Yes Erik! Both the servers are residing on Windows 2003 server.

The script file directory is valid. The failure is not happening everyday for the same database. The behaviour is totally inconsistent w.r.t. to the database. Today, the transfer of objects from database A might fail, tomorrow it happens with database B.

Any clue would be appreciated.

Thanks,

Suesh

Dzenan SSC Rookie Points: 33 More actions · Answer 3

I did figure out that you could solve this problem giving modify access (NTFS) to your script file directory for user who crates DTS. At least it helps me

Elaine França Tavares Beraldo Grasshopper Points: 17 More actions · Answer 4

Hi Suresh,

I have the same problem...

Can you helpme?

Thanks in advance,

Elaine Beraldo

fglazenburg SSC Rookie Points: 41 More actions · Answer 5

I also fixed the problem by assigning a map with write access to the script path.

Regards,

Frank

francsca bertani Grasshopper Points: 21 More actions · Answer 6

we solved it giving access to the user that runs the dts package to the folder:

c:\program files\microsoft sql server\80\toolswhere the file servername.database.LOG is located

norse hedgaardt SSC Journeyman Points: 81 More actions · Answer 7

I have this same problem on SQL 2005 SP3 x64...

Error string: Invalid OLEVERB structure

but this is not a permission problem in this case (been done that road already!).

I cannot seem to find any fix for this - anyone else got any suggestions?

I wish and wish Microsoft could produce software that gives error messages that were useful!

Give us the 'where' and 'why', instead of just 'invalid flibflobblbob structure type boll@cks' !!! :w00t:

gatorspike SSC Journeyman Points: 90 More actions · Answer 8

I am researching this same problem on WS2003 and SQL Server 2000. We had ODBC problems after installing security patch "Security Update for Windows Server 2003 (KB2229593)". They were resolved after removing patch. This may be same problem but have not yet done the permission exercise.

Gary Nease SSC-Addicted Points: 424 More actions · Answer 9

Mine was caused by name collision between two processes both using instances of the DTS "Copy SQL Server Objects Task" component. It scripts objects to the folder mentioned above, and in my case collided intermittantly on the "<servername>.<dbname>.DP1 or .DP2 files, which it generated identically for two logic branches (one doing schema-only objects, the other doing data-copy). I changed the step-dependency to serialize those steps, and the problem went away. It's a design issue IMHO; the DTS-generated filenames of the parallel processes could have included a guid.

Regards,

Gary