Hi Helen,

I'm running the normal production version and using the same client as server. 2.1.2 32bit.

The delete statement is doing this:
Delete from atable
Where Primary_Key < :max_PrimaryKeyToDelete;

Firebird should not get into the position of deleting the same record in the same transaction, should it?

I'm running the same delete in multiple threads and I don't understand under what circumstance is the first error acceptable.
If the message is correct then it sounds like a defect somewhere, whereas if the message is wrong I'm wondering what is the actual correct message?

Cheers,

Calin Pirtea

 
At 12:37 PM 25/09/2009, you wrote:

>Hi All,
>
>ISC ERROR CODE:335544382
>
>ISC ERROR MESSAGE:
>cannot update erased record
>
>I get this error during a delete statement and I do not understand what
>happens to trigger it.

My deduction is that you're trying to hit the same record twice in a single transaction. Fb 2.1 objects to it (whereas earlier Firebirds didn't) and is throwing a hard-coded error string on the 'random error' bandwagon.

>The error I usually get (and expect) is:
>ISC ERROR CODE:335544345
>
>ISC ERROR MESSAGE:
>lock conflict on no wait transaction
>deadlock
>update conflicts with concurrent update
>concurrent transaction number is 146304

That would occur if the delete and the update were requested from *different* transactions.

>This is not a production error but an extreme test case that performs a
>lot of random inserts, selects and deletes.
>
>Can someone please explain if the top error is normal?

If it is what I think it is then yes, it would be normal in v.2.1 and later. And, if it is what I think it is then it means either
1) someone hasn't popped that new error into messages.fdb yet so it needs a tracker report;
or
2) you are using an old client lib

Are you running in Debug mode?

./heLen