Bingo. Your update statement should validate that the initial value is still the same.
Case in point has someone else updated the same row while you were looking at it? Sent from my iPhone Stephen Russell 901.246-0159 On Nov 21, 2010, at 3:58 PM, Davej <[email protected]> wrote: > I'm not sure I understand optimistic locking. The only way I can see > it working is if the client can send a message to the DBMS saying "I > want to update table-row-cell xyz to a new value y if the current > value is still x otherwise abort and return error." > > On Nov 15, 2:55 am, Jamie Fraser <[email protected]> wrote: >> If you are using TableAdapters/DataSets, pretty much all of that is handled >> for you automatically. >> >> Concurrency is also handled, depending on the options you specified when you >> created the TableAdapters - optimistic concurrency is generally best for >> everything as it avoids locking. >> >> On Thu, Nov 4, 2010 at 2:49 PM, Davej <[email protected]> wrote: >>> I'm looking for a basic outline of the steps that are usually used in >>> a multi-user database app. So far I've only played with the single- >>> user situation, so when I load the form I load the form's datagrid... >> >>> Try >>> Me.TblMy_TableTableAdapter.Fill(Me.My_DBDataSet.tblMy_Table) >>> Catch ex As Exception >>> MsgBox("Database Error: " & ex.Message) >>> End Try >> >>> And then when the user exits the form I simply save... >> >>> Try >>> Me.Validate() >>> Me.TblMy_TableBindingSource.EndEdit() >>> If Me.My_DBDataSet.HasChanges = True Then >>> If MsgBox("Post Edits to Remote Database?", MsgBoxStyle.YesNo, >>> _ >>> "UPDATES PENDING") = MsgBoxResult.Yes Then >>> Me.TableAdapterManager.UpdateAll(Me.My_DBDataSet) ' update >>> remote database >>> End If >>> End If >>> Catch ex As Exception >>> MsgBox("Database Error: " & ex.Message) >>> End Try >>> Me.Close() >> >>> Now what is the outline of the save operation for a simple non- >>> cascading multi-user situation? I'm thinking you probably want/need to >>> identify your updates, inserts and deletes and then go through some >>> sort of read-lock-write-unlock loops? I have no idea. I have no >>> exposure to this more complex stuff at all. >> >>> Thanks, >> >>> Dave
