Subject | Re: [IBO] Exception "multiple records inserted" |
---|---|
Author | Eyal |
Post date | 2005-01-06T14:26:09Z |
Helen,
First of all, thanks again for your help.
get an exception.
IBComponents.pas). After the Raise statement there's a lot of code
which doesn't get executed.
Commit. If I do try to call Commit, I get a duplicate insert.
don't call Commit. For the sake of covering all bases I did try to
call Commit anyway. But this resulted in a duplicate insert and both
inserts were NOT commited until I exited the application.
Looking at the code in TIB_UpdateSQL.SQL_Insert, I think that this
"notification exception" is called too early, so some things are left
half baked, without any way (that I'm aware of) to finish them off
properly.
For now I just commented out the test for AffectedRows>1, because I
don't really care to lose this warning. However I think that IBO
should be fixed - either raise the exception later in the code, or
provide a property to avoid non-critical exceptions.
Many thanks for your enthusiastic assistance.
Eyal.
First of all, thanks again for your help.
> This is not a database exception. You catch the exception andI don't raise any exception! All I do is call MyDataset.Post, and I
> swallow it...meaning, you don't raise it!
get an exception.
> IBO throws this exception *after* Post.IBO throws the exception in the middle of TIB_UpdateSQL.SQL_Insert (in
IBComponents.pas). After the Raise statement there's a lot of code
which doesn't get executed.
> Look, somewhere in your code, you must call Commit.The transaction I use has AutoCommit=TRUE, so I don't have to call
Commit. If I do try to call Commit, I get a duplicate insert.
> Don't raise it!! You only raise it if you want *the exception*I don't raise it, I swear, honest to God, it's IBO...
> to be handled outside. In this case, you want to handle it by
> catching it and ignoring it, so that your procedure can continue.
> OnError is for database exceptions. This is no database exception,Ok, thanks for the explanation.
> so OnError doesn't get called. It's also not an *error*. It's a
> notification - basically it is saying "Inserts normally return only
> one row affected. This one returned more than one. What do you
> want to do?"
> Write the block like thisThat's exactly what I tried. My transaction is on AutoCommit, so I
> begin
> ....
> with myStatement do
> try
> Post;
> except
> on E:E_Multiple_Records_Inserted do
> begin
> // Gulp! Exception swallowed.
> end;
> end;
> // Program control passes to here.
> // if you want to commit here, do so.
> // if not, the row stays posted and
> // awaits the commit if/when it happens.
> ...
> end;
> Note: If the transaction was set to AutoCommit, then the Post call
> will have already committed the transaction.
don't call Commit. For the sake of covering all bases I did try to
call Commit anyway. But this resulted in a duplicate insert and both
inserts were NOT commited until I exited the application.
Looking at the code in TIB_UpdateSQL.SQL_Insert, I think that this
"notification exception" is called too early, so some things are left
half baked, without any way (that I'm aware of) to finish them off
properly.
For now I just commented out the test for AffectedRows>1, because I
don't really care to lose this warning. However I think that IBO
should be fixed - either raise the exception later in the code, or
provide a property to avoid non-critical exceptions.
Many thanks for your enthusiastic assistance.
Eyal.