Subject | Re: [IBO] defective datapump program |
---|---|
Author | Helen Borrie (TeamIBO) |
Post date | 2002-01-22T01:42:54Z |
At 02:18 AM 22-01-02 +0100, you wrote:
What you need to do is trap the exception in a way that allows the transaction to continue. What your exception code is doing is FIRST killing the transaction and THEN attempting to send a message to the user. Of course, by that time the exception has already been raised and the confirm dialog is fruitless.
Create a proper exception handler to trap a rogue record, perhaps to log the offending record out to an external file, and let the transaction continue. Don't call Rollback unless you *want* the transaction rolled back.
Also, look at taking explicit control of the transaction and deferring the call to Database1.Commit until the pump is complete.
regards,
Helen Borrie (TeamIBO Support)
** Please don't email your support questions privately **
Ask on the list and everyone benefits
Don't forget the IB Objects online FAQ - link from any page at www.ibobjects.com
>using D3 and IBO v. 3.6.Dj, I built my datapump program.That is what Rollback does! The whole idea of Rollback is that, if the transaction is not to be committed (in entirety), then it is rolled back (in entirety).
>
>Actually it is a very simple program that uses 2 TIBOTable and 1 TDatabase.
>
>The TIBOTables are SrcTab e DstTab.
>
>SrcTab opens a local DBF e DstTab opens an identical FB table.
>
>For each record in SrcTab, the following code is run (StrLst contains the
>field names common to the 2 tables) :
>
>
>function TForm1.PumpData:boolean;
>var
> i:integer;
> s:string;
>begin
> result:=True;
> try
> Database1.StartTransaction;
> DstTab.Insert;
> for i:=0 to StrLst.Count-1 do
> begin
> {read field name}
> s:=FieldName(StrLst,i);
> {copy field value}
> DstTab.FieldByName(s).Value:=SrcTab.FieldByName(s).Value;
> end;
> DstTab.Post;
> Database1.Commit;
> except
> Database1.Rollback; {1}
> result:=me_ask('continue ?')=mrOk;
> end;
>end;
>
>When/if an exception is raised, a Rollback is executed and the user is
>prompted to choose btw going ahead (skipping the offending record) or to
>stop (the calling routine takes care of stopping the application).
>
>The code works...almost :)
>
>What happen is: after a rollback is done, rollbacks are _always_ done for
>all the subsequent - completely potable and innocent - records.
>
>I cannot see the reason for that.
>
>It seems that the exception is not trapped by the try...except...end
>statement.
>
>How is that possible ?
What you need to do is trap the exception in a way that allows the transaction to continue. What your exception code is doing is FIRST killing the transaction and THEN attempting to send a message to the user. Of course, by that time the exception has already been raised and the confirm dialog is fruitless.
Create a proper exception handler to trap a rogue record, perhaps to log the offending record out to an external file, and let the transaction continue. Don't call Rollback unless you *want* the transaction rolled back.
Also, look at taking explicit control of the transaction and deferring the call to Database1.Commit until the pump is complete.
regards,
Helen Borrie (TeamIBO Support)
** Please don't email your support questions privately **
Ask on the list and everyone benefits
Don't forget the IB Objects online FAQ - link from any page at www.ibobjects.com