Hi Don, Geoff and Jason!

Thank you for your answers. It was indeed a master-detail problem, and not a
Pessimistic Locking one. Now that I understand the problem and the way IBO
handles a master insert, I can find a solution.

Thanks again!
Gabriel

Don Schoeman wrote:

> Can't you temporarily switch pessimistic locking off when inserting a
> row?

Geoff Worboys wrote:

> Update triggers should not be firing during an insert and neither
> should pessimistic locking be called. So I suspect your problem is
> not related to the pessimistic locking settings.
>
> You must be inserting and then updating. This can happen in
> master/detail arrangements where IBO will automatically post a new
> master record but leave the dataset in an apparent insert state so
> that detail items can be created. When you eventually post the master
> in this situation it will actually perform an update, which could be
> when your update trigger is being activated.
>
> I think you will have to examine your requirements to find an
> alternative approach. For example...
>
> * If you specifically want to mark items that are updated from the
> client application, then you can implement specific update of the
> DATA_M field at the client just when the update is posted.
>
> * If the update can be detected via other fields (or perhaps other
> records) then you can update your trigger to detect those changes and
> set the field.
> IF( (SomeField IS NOT NULL) OR (DATA_M IS NOT NULL) ) THEN
> DATA_M = ...
> so if SomeField has been set then DATA_M will be initialised. Once
> DATA_M has been initialised it will update with every update.

Jason Wharton wrote:

> This is the automatic postretaining feature of dealing with
> master-detail relationships and keeping referential integrity in
> place. When the master dataset is in insert state and it has a detail
> dataset post an insert the master does an internal PostRetaining which
> does an insert to the server so that the detail can insert a record.
> Then, when the master is posted it does an update because the insert
> is already there. You can either accept things as they are and deal
> with it or you can use a special column or code for your trigger to
> know it is a post retained insert and to ignore applying that
> timestamp.