Cursor behaviour with cached updates
From: Dave Blake (barnswood_at_hotmail.com)
Date: 01/22/05
- Next message: Dave Blake: "Re: Cursor behaviour with cached updates"
- Previous message: CC: "Re: How to obtain a number of last record in Database"
- Next in thread: Dave Blake: "Re: Cursor behaviour with cached updates"
- Reply: Dave Blake: "Re: Cursor behaviour with cached updates"
- Reply: Del M: "Re: Cursor behaviour with cached updates"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sat, 22 Jan 2005 06:30:47 -0000
I am trying to use BatchOptimistic locking and client side cursors to
provide local working (prior to save) in a multi-user app (Jet 4.0 DB),
specifically on a master/details/deatils form but let's just look at
master/details to begin with.
Master and details are linked ADODatasets using datasource and MasterFields
properties (rather than parameters to avoid the details being required
everytime the master changes state). All looked good until I found some
weird cursor behaviour while there were cached changes (prior to
updatebatch).
Having inserted (and posted) a new details record navigation to other
details records is fine. But if subsequently the dataset is set into dsEdit
while cursor on such a record and yet no fields changed, then navigation to
another record (without explict post) causes the dataset to get "lost".
Likewise, edit values in record A and navigate to another record (next
button, or mouse on grid etc.), the values are implictly posted. Return to
record A, edit values again, move etc. eveything looks fine. Now return to
record A, explictly change to edit state (say details.edit on a button
click) but change no values. This time navigation to another record causes
*all* the changes to record A to be lost.
It would seem that the implicit post during moving while dataset in dsEdit
state from a record with previously cached changes but where there are no
changes to post, requeries the original values. Hence getting "lost" if the
record is new.
I don't know why it does that, or what I can do about it. Suggestions?
Try and catch all cursor movement and do an explictit post I guess, or
always change a field value when change to edit state. Has anyone noticed
this behaviour before?
Cheers
Dave
(Wondering why cached updates are so hard)
- Next message: Dave Blake: "Re: Cursor behaviour with cached updates"
- Previous message: CC: "Re: How to obtain a number of last record in Database"
- Next in thread: Dave Blake: "Re: Cursor behaviour with cached updates"
- Reply: Dave Blake: "Re: Cursor behaviour with cached updates"
- Reply: Del M: "Re: Cursor behaviour with cached updates"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]