Helen,

The "gotcha" is not a problem of IBO trying to update a computed
field. It is that a (non-computed) field on a table is being updated
by another table through triggers and SPs, or by other users. If
such updates happen between reading the record into a buffer, and
saving the record, then the buffer value overwrites the updated field
value with the old field value.

I don't want to switch on pessimistic locking for this kind of thing,
as such fields are constantly being updated by other users, and the
system would grind to a halt. Instead I add such fields to the
FieldsReadOnly property of IBO, which causes it to skip the field
when composing its EditSQL query. The recurring error is simply that
I sometimes forget to do this.

Roger Vellacott
Passfield Data Systems Ltd




--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@...>
wrote:

>
> At 03:32 AM 14/10/2007, rogervellacott wrote:
> >Helen, thanks for your response.
> >
> >Problem solved I think. The "unreliable" field needed to be

excluded

> >from the update SQL on a client query.
>
> Not sure.... You should get an exception at Prepare time if your
> update statement targets a computed field. If IBO is beneath this
> app, it shouldn't even get that far, as a local exception should be
> thrown on a non-updatable field before the statement even goes to
> prepare. So, if your application code is not using some workaround
> to avoid the exception and you can reproduce that condition with a
> simple demo, it needs to be reported as a bug in one place or the

other.

>
> >The value updated by the trigger was being inadvertently

overwritten

> >by the client app.
>
> That's a different problem.
>
> >This is not the first time this gotcha has got me.
>