At 12:56 AM 16/02/2004 +0000, you wrote:

>
>When the AfterPost event is invoked at line 6, IBO still has the
>dataset as 'IsPosting'. Hence the secondary update attempt (from
>within the AfterPost event) is forestalled at line 1, even though the
>dataset's state is then dssBrowse (line 5).

Andy, either I'm missing your point or you're missing mine. If you applied
the new column values in the BeforePost, then they will already have been
posted by the time you reach AfterPost.

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. Hence my original feedback - Why? (Why are you attempting
to "double-post"?)

Going back several paces, we come to another "Why?" Why are you using the
client to perform an update that ought to be handled (for the sake of data
integrity) by AfterUpdate, AfterInsert and AfterDelete triggers on the
detail table? Your approach locates an essential business rule in client
applications (all others, in addition to your current one), which is
inherently a risk to the integrity of your data. What happens if Mr Clever
User installs an admin tool that lets him insert ad hoc detail rows, or
writes a rules-unaware PHP script to do the same thing?

There's another important design problem here: storing values on that
master record that are dependent on "good behaviour" from a lot of
players. Why not store these values as computed columns or, if you only
need them in user interfaces, define them as run-time output? (Directly, as
expressions in your SELECT statement, or indirectly, by defining an
updateable view on the master).

Helen