This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C087D2.E3D76540
Content-Type: text/plain;
	charset="iso-8859-1"

The two suggestions that were forwarded are really more of what I have been
hearing, basically the idea of telling or showing the person the the data
has changed so they have the option of overwriting those changes by saving
their stuff or refreshing their own records and losing whatever work they
have done. Once again it sure doesn't seem real graceful. I might have said
this before but the first time I heard about disconnected recordsets I asked
the MS presenter about this very issue and he said "Well you'd have to code
for it" and quickly changed the subject. I have often thought that the way I
might handle it "If I had to" Was to only have the one editable record in
the recordset and then once that is written back to the database, if there
is a conflict then bring up 2 very generic forms that displays both records
with changes highlighted and allow the user to either Overwrite/Update
Merge/Reedit the latest record. There would be a lot of stuff to workout
with this approach but I think it might work. I do believe that using
disconnected recordset is one of those things that's talked up alot but not
used in the kind of applications I'm thinking of: Namely a bunch of users
updating the same bunch of records all the time. 
Shawn

-----Original Message-----
From: Chris Ellegood [mailto:jcellegood@h...]
Sent: Friday, January 26, 2001 12:07 PM
To: professional vb
Subject: [pro_vb] RE: Some Thoughts and Questions on Object Oriented
programming, Middle Layer vs Stored Procedures etc


Hmm.. I am not sure what any alternatives would be... you wouldn't want to
summarily either admit the change for user 2 or discard user 2's changes to
the recordset.  I think typically the choice is give whether they want to
save their changes anyway or to refresh the dataset.  
 
Thanks.
 
Chris Ellegood, ATP,  xxx-xxx-xxxx
 
--
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments,
is for the sole use of the intended recipient(s) and may contain
confidential and privileged information.  Any unauthorized review, use,
disclosure or distribution is prohibited.  If you are not the intended
recipient, please contact the sender by reply e-mail and destroy all copies
of the
original message.

----- Original Message ----- 
From: Gamble, Shawn <mailto:Shawn_Gamble@S...>  
To: professional  <mailto:pro_vb@p...> vb 
Sent: Friday, January 26, 2001 1:00 PM
Subject: [pro_vb] RE: Some Thoughts and Questions on Object Oriented
programming, Middle Layer vs Stored Procedures etc



>> As for the ADODC and binding...personally I never, ever use them.
Binding makes concurrent data se

>> challenging and kills extensibility.
 
I don't want to start a religious war here but I was wonder how you deal
with conflicting records in this case. Suppose User 1 grabs a recordset with
100 records in or even one record in it and disconnects from the datasource.
Then user 2 grabs the same 100 records or one record and disconnect. Now
they both edit exactly the same record and submit the changes. User 1s
record get written No conflict. Now user 2 tries to write the record and
because of error handling code / time stamping etc... you discover something
is wrong. Now at this point a conflict occurs and the question becomes what
do you do? Most examples I have seen said well you notify the user 2 and
tell him he can over write user 1's changes or he can discard his work and
regrab the newest record. This however seems very sloppy and irritating. So
for anyone out there using Disconnected Data, How are you handling it?
 
Thank You
Shawn