Row handle referred to a deleted row or a row marked for deletion

  • 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

  • [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]

  • 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.

  • [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]

  • 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