Subject | Re: [IBO] How to get the record id that was just stored with a query |
---|---|
Author | Helen Borrie |
Post date | 2005-06-30T22:36:27Z |
At 10:23 PM 30/06/2005 +0300, you wrote:
the field value in BeforeExecute. The important thing is to store the
value in some structure that will survive the completion of the operation -
and, of course, to nil the value once there is no longer any interest in it.
Use Autocommit only with great care. Be careful that you do not isolate
your insert operation from other data that are going to use that stored
value. If that operation is a piece of a broader task, then you should not
be using Autocommit for the separate pieces of the task. The whole purpose
of a transaction is to "throw a rope around" multiple operations, to keep
the state of data consistent for each and every operation until the task is
either completed (by committing) or backed out (by rolling back).
Helen
> >>I tried using GeneratorLinks, and it works otherwise except that IWhat statement class are you using? If it is an IB_DSQL, then just grab
> >>couldn't
> >>figure out how to read the id back. Anyone up for a wee little piece of
> >>sample code? ;-)
> >
> > Sample code not needed! All you have to do is read it in any Delphi event
> > *after* IBO's AfterInsert has fired. BeforePost is a good place. Pull
> > FieldByName('id').AsInteger into a variable or, better still, set a
> > property.
>
>BeforePost for that query doesn't fire, what could be the reason for that?
>Is it maybe because my Transaction component is set to autocommit, and so in
>my code I only call Query.Execute? The record is inserted and everything
>otherwise seems to work ok.
the field value in BeforeExecute. The important thing is to store the
value in some structure that will survive the completion of the operation -
and, of course, to nil the value once there is no longer any interest in it.
Use Autocommit only with great care. Be careful that you do not isolate
your insert operation from other data that are going to use that stored
value. If that operation is a piece of a broader task, then you should not
be using Autocommit for the separate pieces of the task. The whole purpose
of a transaction is to "throw a rope around" multiple operations, to keep
the state of data consistent for each and every operation until the task is
either completed (by committing) or backed out (by rolling back).
Helen