Subject | Re: [IBO] Re: IB_Query remains in EditMode after Posting |
---|---|
Author | Helen Borrie |
Post date | 2004-02-18T10:01:05Z |
At 08:38 AM 18/02/2004 +0000, you wrote:
of parameter values from the current row, massages them into the Update,
Insert or Delete statement and submits that statement to the
server. IsPosting is still true at AfterPost before AfterPost is part of
the atomic event. It goes False at some point *after* AfterPost, when the
event is complete; then the dataset goes back to dssBrowse. You can use
AfterPost for things like updating a counter or storing the OLD_ or NEW_
values somewhere, setting some flag, etc. - it's your last chance to grab
those bits and pieces before committing.
H.
>--- In IBObjects@yahoogroups.com, Helen Borrie <helebor@t...> wrote:Yes, the whole Post event is an atomic client-side event that takes a set
>
> > 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.
of parameter values from the current row, massages them into the Update,
Insert or Delete statement and submits that statement to the
server. IsPosting is still true at AfterPost before AfterPost is part of
the atomic event. It goes False at some point *after* AfterPost, when the
event is complete; then the dataset goes back to dssBrowse. You can use
AfterPost for things like updating a counter or storing the OLD_ or NEW_
values somewhere, setting some flag, etc. - it's your last chance to grab
those bits and pieces before committing.
H.