| Subject | Re: [IBO] How to make BeforeUpdate updated fields appear afterEdit and Insert? |
|---|---|
| Author | Helen Borrie |
| Post date | 2002-10-25T22:57:32Z |
At 02:22 AM 26-10-02 +0930, you wrote:
The Edit and Insert events are client-side events. It is not until a Post
is called following one of these events that the server even "knows" that
the user was editing or inserting anything. Post causes IBO to construct
DML statements (INSERT INTO... or UPDATE... or DELETE FROM...), passing
parameters from the current row in the client buffer to fill out the DML
statement. It passes the statement to the client library gds32.dll (or
gds.so) which proceeds to submit the request.
On the server side, assuming the engine accepts the request, it performs
the operation and creates a new recversion. Inside this recversion will be
the newly calculated values for the triggered columns. However, the client
transaction cannot see the new recversion - it still holds its view of
original copy of the row (in the case of updates and deletes) and its
original view doesn't contain any inserted row.
Triggers are server-side events. The DB engine doesn't support dirty reads
so obviously there is no way that the client can somehow requery the
database to look at the new (uncommitted) recversion and extract the
triggered values.
Once the transaction is committed, the new row (or the row with its
changes, including the triggered ones) will become accessible to the client
and can be made visible to your application.
Relating to this situation, applications often need to know the value of a
generated primary key (or other column using a generator) *before*
committing anything to the database. This is why IBO has
GeneratorLinks. It is fine for a client application to "pre-book" a
generator value, since generators are independent of any client
transaction. If a generator value is fetched and subsequently abandoned by
cancelling the insert, nothing is lost except the continuity of the
generated numbers in the table. This isn't a problem, since we don't care
if there are gaps in the sequence - only that the numbers be unique.
IOW, if you want the user to see the prospective effect of triggered
changes, you will have to create some calculated fields in your client that
perform the equivalent calculations.
Helen
> > >When using a TIB_Grid attached to TIB_Query that displays auto-updatedThe short answer is "No". The long answer is as follows:
> > >fields, how does
> > >one make them appear after Edit and Insert?
> >
> > Please explain what you mean by "auto-updated fields".
>
>1. Fields that are provided in BeforeUpdate Triggers; e.g. a capitalised
>field for fast
>case-insensitive searches or calculated fields based on the NEW values
>provided by the
>user.
>
>2. Fields that are provided by AfterUpdate Triggers; e.g. calculated
>fields based on the
>NEW values provided by the user.
The Edit and Insert events are client-side events. It is not until a Post
is called following one of these events that the server even "knows" that
the user was editing or inserting anything. Post causes IBO to construct
DML statements (INSERT INTO... or UPDATE... or DELETE FROM...), passing
parameters from the current row in the client buffer to fill out the DML
statement. It passes the statement to the client library gds32.dll (or
gds.so) which proceeds to submit the request.
On the server side, assuming the engine accepts the request, it performs
the operation and creates a new recversion. Inside this recversion will be
the newly calculated values for the triggered columns. However, the client
transaction cannot see the new recversion - it still holds its view of
original copy of the row (in the case of updates and deletes) and its
original view doesn't contain any inserted row.
Triggers are server-side events. The DB engine doesn't support dirty reads
so obviously there is no way that the client can somehow requery the
database to look at the new (uncommitted) recversion and extract the
triggered values.
Once the transaction is committed, the new row (or the row with its
changes, including the triggered ones) will become accessible to the client
and can be made visible to your application.
Relating to this situation, applications often need to know the value of a
generated primary key (or other column using a generator) *before*
committing anything to the database. This is why IBO has
GeneratorLinks. It is fine for a client application to "pre-book" a
generator value, since generators are independent of any client
transaction. If a generator value is fetched and subsequently abandoned by
cancelling the insert, nothing is lost except the continuity of the
generated numbers in the table. This isn't a problem, since we don't care
if there are gaps in the sequence - only that the numbers be unique.
IOW, if you want the user to see the prospective effect of triggered
changes, you will have to create some calculated fields in your client that
perform the equivalent calculations.
Helen