--- In IBObjects@yahoogroups.com, Helen Borrie <helebor@t...> wrote:

> Andy, either I'm missing your point or you're missing mine.
> If you applied the new column values in the BeforePost ...

I've made sure I now do, and that has removed the problems.
Many thanks for the pointer. And also for the good advice about
placing the business rules on the server.

> Post is a client-to-server action: it creates a new record
> version on the server. You can't use AfterPost (a client event)
> to add a further new record version.

Is it then that the client AfterPost event isn't truly *After*
Post, but is *Almost* After Post? I'm thinking that the App would
be free to make a further update (= add new record version) once
the AfterPost event has completed, so I'm curious as to why it
isn't possible during the event.

Maybe someone would offer confirmation (or rebuttal) of my analysis
below:

The core of TIB_Dataset.SysPost is essentially:

01 if not IsPosting
02 try
03 IsPosting := True;
04 SysBeforePost;
05 SysExecPost;
06 SysUpdateState
07 SysAfterPost;
08 finally
09 IsPosting := False
10 end;

When an AfterPost event is invoked at line 7, IBO has put the
dataset to dssBrowse (line 6) but still has the dataset
as 'IsPosting' from line 3. This appears to be to be the problem (or
is it intentional?). Either way, a secondary update attempt from
within the AfterPost event (ie a second call to SysPost while the
first is still active) is stalled at line 1 becasue IsPosting is then
still True.

Thanks, Andy.