June 18, 2008 at 10:24 am
I have a Storec proc that is scheduled as a job. Some times the job fails and some times it throws the following error
------
Could not get the data of the row from the OLE DB provider 'SQLOLEDB'.
[OLE/DB provider returned message: Row handle referred to a deleted row or a row marked for deletion.]
-----------
The job has 55 steps and it fails at step 37 which is update
UPDATE ad
SET ad.[Value] = [DR_TOD]
fromEDI_xref_ConEd_TOD
INNER JOIN a
INNER JOIN ad ON a.NE_AcctNo = ad.NE_AcctNo)
INNER JOIN n ON a.NE_AcctNo = n.NE_AcctNo) ON EDI_xref_ConEd_TOD.DR_TOD = substring(n.EDC_RateSubclassCode,6,3)
Where
--------------------------
Before step 12 there is a delete statement on one of the tables "n" referred above.
Is it becuase the row is marked for deletion at that step is not comitted yet and we are referencing this later? Any suggestions
June 19, 2008 at 1:47 pm
[font="Arial"]
Hello,
I don't have a solution but I do have a couple comments and questions that might help.
In the UPDATE you are updating ad. It should be the first table in your from clause and the associations to the other tables should be after it in the most logical direct manner.
Secondly, I note you are using a OLE provider that makes me suspect you are doing a distributed computing scenerio...is this the case?
Regards,
Terry
[/font]
June 19, 2008 at 2:01 pm
Thanks for the attention to detail . Is it mandatory that we need to have ad as the first table?
I am not using any OLE DB Provider as such but the undelying SQL tables are having some triggers which might be fired from the front end MS ACCESS application while this proc is running. That might be having some conflicts with this proc.
June 19, 2008 at 2:13 pm
[font="Arial"]
Hello,
This error :
Could not get the data of the row from the OLE DB provider 'SQLOLEDB'.
[OLE/DB provider returned message: Row handle referred to a deleted row or a row marked for deletion.]
Must be from the interface to MSACCESS as SQL doesn't "mark" a row for deletion. If the front end user marks a row for deletion during the processing of the UPDATE on the backend ( SQL ) then that would explain why when the update got to one such row it would pump out the error.
The UPDATE is linked to the front end and it's using techniques that are not SQL based.
Sorry not to have been more help.
Regards,
Terry
[/font]
June 19, 2008 at 2:22 pm
Thanks a lot. The information you gave is good for me to change the scheduling of the job as the job never failed at 6.00 AM when business is not using the app.
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply