Hi,
One of my jobs which reads data from a sql server table and writes to a flat file is aborting. I am using MSOLEDB stage to read the data.
The error given in the log file is
DataStage Job 1372 Phantom 2524
Program "DSP.Open": Line 122, Exception raised in GCI subroutine:
Access violation.
Attempting to Cleanup after ABORT raised in stage CopyOfCopyOfagtmonitor1..MS_OLEDB_18
DataStage Phantom Aborting with @ABORT.CODE = 3
I checked the RT_BP1372 folder and the file within it and line no 122 is
in and TEMP1 are the input and output links respectively.
Is the error occuring becos of no provision for rows rejected by transformer. how to see whats in V50S0P2 location. Any help will be appreciated.
TIA
gradkarthik
the line number displayed is not the exact line number of the error message; you need to offset this by up to a couple of lines (this is due to the way the compiler works and has been a problem for years...). The line you listed is a comment, just look downwards to a line that issues an external call to find the appropriate error location.
Can you do a view data in the designer on this? As the previous poster mentioned, it might be as simple as an invalid userid/password or other configuration error.
The "access violation" is not a database or OS message, it states that the program has attempted to change a memory location that is read-only. This usually occurs when a pointer (to a variable) isn't set. Often it is the result of bad programming, but in cases like this it means that some variable hasn't been initialized or returned correctly.
Hi guys,
I checked the user id and password and tried running the job by hardcoding the values rather than using parameters. It still failed. The funny part is when I replace the MSOLEDB stage with the ODBC stage, the job runs fine without a hitch. So can rule out the incorrect user name or password problem.
Its only when the job contains the MSOLEDB stage that it fails.
I tried running the same job in different test projects and in one of the project, the line no 122 (which is always the same) was as follows:
The program that is failing at line 122 is DSP.OPEN (I wasn't paying attention to your first post...); at line 122 it issues call to the globally catalogued routine "$DSP.Open"; so the line number doesn't help much further.
Are you able to get any MSOLEDB stage to work on your system?
Hi ArndW,
Thanks for you reply. I have other jobs which have MSOLEDB stages in them and they run fine. Its just this new job that i am developing that is failing.
gradkarthik
Hi guys,
I solved the problem. I had unknowingly left the field where you specify the table names in MSOLEDB stage blank. I was using a user defined sql query but the MSOLEDB stage still requires something to be present in the table name(s) field for the job to run successfully.
Its wierd because i use some other stages like Informix CLI and it allows the table field to be blank if using user defined sql. So i had just assumed that MSOLEDB was no different.
I ran my jobs again with MSOLEDB stage but this time i just entered some random value in the Table field (eg. abc) and the jobs run fine.
I don't know if this is a bug with MSOLEDB stage or it was meant to behave this way.
Thanks guys. :D
gradkarthik
I had unknowingly left the field where you specify the table names in MSOLEDB stage blank. I was using a user defined sql query but the MSOLEDB stage still requires something to be present in the table name(s) field for the job to run successfully.
Its wierd because i use some other stages like Informix CLI and it allows the table field to be blank if using user defined sql. So i had just assumed that MSOLEDB was no different.
I have a question, when we use a user defined sql query, we need to provide the table name also (not sure its true with all the db stages or not), for what purpose DataStage uses it, may be it allocates the buffer for the rows under that name in the memory.
I think it uses the table name to validate the columns in your design when the connection to the database is established but before the request to prepare the SQL is issued.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
I dont think it validates the columns because I just entered "abc" in the Table name(s) field and still the job ran without any problem. Its probably uses the value in that field to allocate buffer memory or its just the way MSOLEDB was supposed to work.
</a>
