May 28, 2004 at 11:23 pm
I'm getting a "DTSRun.exe Application Error, the instruction at 0x77fcb3ad referenced memory at 0x00000000 "Memory could not be written"
This is on a Windows 2000 advanced server SP 4, SQL Server 2000 SP 3 set up as a clustered server.
I have done a web search and nothing jumped out and grabbed me. Msoft said there was a similar DTS bug but this was supposed to be fixed at SP 1.
The DTS job executes ok by "Execute" from the DTS folder in EM - just the sheduled job gives back the error.
The job connects to an Oracle 9i RAC and the local SQL server and then sucks data from an Oracle view to a table in the desired SQL database. All notifications are handled by the Scheduler.
Other sheduled jobs run just fine naturally.
Aaargh !
Can anyone help ?
The systems fine with no users loggged in. Can we keep it that way ?br>
May 29, 2004 at 8:16 am
Are any other packages connecting to an Oracle server and if not then are any other connectig to a SQL Server?
I assmue that would be yes, if so then do you get the error when you run the open package manually?
If no then are you executing the package on a remote machine and not on the Server machine? If yes then did you make sure you installed the Oralce drivers on the server as when you run on a remote machine the oen package uses whatever local resources are available to that machine not the server. If no then remove the Oracle connection and all related pieces and do a simple select in a query object on the sql connection and save (remember DTS has a versioning system so you old work is still there) then run, see if it still fails.
If the manual run fails then remove the Oracle stuff and do a simple select in a quey task on the sql server object and run.
If remove the Oracle pieces works and the drivers are on the server then you may have either a permissions issue, Oracle client install issue (wrong version, corrupted install, etc.), or an MDAC issue (but that is probably not it).
If removing the Oracle pieces then I am suspecting an MDAC issue go download the latest from MS and test.
Let us know what you discover.
June 15, 2004 at 10:33 pm
Eventually success:
I had to go into design and open the two odbc connections, check clear transformations on cloing the properties windows, save and THEN change the owner to the account used to manage the agent !!
Luckily it didn't actually clear any transformations I could see. (What the ?)
Used sp_reassign_dtspackageowner to change the owner
| sp_reassign_dtspackageowner [@name =] 'name', [@id =] 'id', [@newloginname =] 'newloginname' |
[@name =] 'name'
The package name.
[@id =] 'id'
This is the uniqueidentifier for the package. A name may not necessarily be unique.
[@newloginname =] 'newloginname'
The new Owner name. SQL Server login example 'sa', NT Integrated example 'Domain\Username'
If you look at sp_reassign_dtspackageowner you'll notice that it not only updates the owner text field, but it also updates the owner_sid field. It also handles error checking.
Might have been easier just to re-create the package......
DB
The systems fine with no users loggged in. Can we keep it that way ?br>
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply