Subject | Re: Has the GSG been updated? |
---|---|
Author | Marco Menardi |
Post date | 2004-06-27T17:07:17Z |
--- In IBObjects@yahoogroups.com, Raymond Kennington <progsol@c...> wrote:
many suggestion of clarification of the text. A "experienced newbie"
feedback should be considered very valuable for a GSG, OMHO.
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.
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.
thanks
Marco Menardi
> Helen Borrie wrote:concepts and
> >
> > At 09:45 PM 20/06/2004 +0930, you wrote:
> >
> > >--
> >
> > No.
> >
> > What would like in there? Taking suggestions....
> >
> Helen,
>
> I suggest starting with all the corrections I've provided to text,
> diagrams in my multitudinous posts in 2003, including those thatwere not
> answered or not explained.I subscribe your request. I noticed the question you asked, and the
many suggestion of clarification of the text. A "experienced newbie"
feedback should be considered very valuable for a GSG, OMHO.
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.
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.
thanks
Marco Menardi