At 05:07 PM 27/06/2004 +0000, Marco Menardi wrote:

>My "addition suggestion" is a "definitive" clarification of
>cuncurrency management, like when you have to update financial values
>in accounting programs, expecially if you have to "lock" several
>detail rows to prevent others to make changes if you do in any of
>them. Currently I've solved the problem with a "conflict" table where
>I store the ID of the master record as PK, and use it with
>"pessimistic lock" of IBO, but I'm very confused about all the
>"multigenerational low lock conflict" stuff in these situations. Maybe
>this shoud be better put in a separate tech sheet, though.

Agreed, it would be good as a tech sheet. It's not beginner stuff and it's
a database design problem, rather than a problem that a client interface
should (or could) try to solve by hacking. The database itself is
responsible for locking dependent detail rows when there's a lock on the
master. Like it or not, it's not the purpose of the GSG to teach people
the basics of database design and referential integrity. Tech sheets, OTOH
can be a great help for suggesting solutions to specific problems.

Related to this topic are the implications of LockWait and RecVersion in
transaction configurations. The GSG can help better here by providing a
more detailed description of what happens on the server with the variations
of these settings.

>Also would be better clarify that "insert/edit/delete" state are
>"client only", and nothing is done on the server side until send a
>specific (usually IBO automatic generated) SQL command. This will help
>leave the "dbiii/access/paradox" way of thinking.

Agree enthusiastically !!

Thanks,
Helen