multiple users updating a database.

[Tc]

Hi,

I was curious, I am thinking of writing an application that loads a dataset
from a database that resides on a server. The question I have is this, if
multiple copies of the app will be running at once will there be problems
with data updates?

The reason I ask is I'm thinking like this:

User1 launches the app and the dataset is created from the data in the DB.
User2 does the same.

User1 updates row 9 in the db and the information is saved.
User2 updates row 100 in the db and saves the changes.

Does row 9 from User2 (the original row 9) replace the changes that User1
made? or will only the specific changes in that dataset be posted back to
the server?

As you can tell I'm new at this and a bit confused.

Thank you very much..

[Morten Wennevik]

Only one user can write data to the database at any one time but you might
have several users reading the same data.
If there is a chance that other users may write to the same datatable you
need to lock the database while you update the data (and your application
need to handle what happens if the database or table is locked, or maybe
the database will manage it and put you on hold, I'm not quite sure, but
in any case you need to tell the user that someone else have may have
changed the data and do they want to reread the table).
There are different levels of locking as well as different types of
locking.
When updating you only write changes made, so one user would not overwrite
the other one's entry, unless they both update the same row. In that case
you may find that you overwrite his/her changes.

These pages may explain some more about locks:

http://www.sql-server-performance.co...ed_article.asp
http://www.extremeexperts.com/sql/ar...ingBasics.aspx

--
The hotmail account will most likely not be read, so please respond only
to the news group.

[Christopher Kimbell]

Hi,

The DataSet is usually filled using DataAdapters, these objects have a
SelectCommand, UpdateCommand,
DeleteCommand and InsertCommand that cotains standard SQL. Usually there is
one DataAdapter for each
Table in your DataSet.

SelectCommand is called when you call the Fill() method on the DataAdapter.
Update/Delete/InsertCommand are called when you call the Update() method on
the DataAdapter
in response to the RowState for each row in your table. The content of these
commands you can
modify to do whatever you want.

If you drag a table from the Server Explorer to a Form or component, a
DataAdapter is created.
This will contain default implementations for all the commands.

The interesting stuff happens when you want to update the database. The auto
generated DataAdapter
will by default try to update the row that contains exactly the same data it
had when the DataSet was loaded.
Check the SQL and you will se an Update command that checks every column
that you read.

If the Update() fails, an exception is thrown, and you must resolve the
update conflict somehow.

Detecting that data has changed in the database before you perform an
Update() is hard. The easy way is to
just perform the Update() and handle any inconsistency errors that occur. If
you periodically poll for data,
you still have to handle these types of errors. Instead of using bandwidth,
you deal with it when it becomes a problem.
The user may spend some time modifying the data, then decide to cancel the
changes; a lot of code and bandwidth
wasted for a problem that never occured.

If you use SQL Server 2000, I have read of solution that modifies a file
using Triggers. The client application
can then use a FileSystemWatch er to detect when data has changed, then
request the data again and perform
some merger between the new data and the edited data. This solution will
only work over a LAN and it will probably
become very messy. Yukon, the next version of SQL server, apparently has
some notification mechanism we can use.

The conclusion is that updating data from different users at the same time
is not a trivial problem. The type of update
strategy you choose depends on your requirements. Determine what should
happen for the following cases:

1.Two users update different columns on the same row.
2. Two users update the same column on the same row.
3. A user deletes a row, and another modifies data in the deleted row.

The action performed may be different for each table.
Hope this clarified some of your questions.

Chris

"Tc" <[e-mail] > wrote in message
news:ui******** **************@ news.easynews.c om...

Hi,

I was curious, I am thinking of writing an application that loads a dataset from a database that resides on a server. The question I have is this, if
multiple copies of the app will be running at once will there be problems
with data updates?

The reason I ask is I'm thinking like this:

User1 launches the app and the dataset is created from the data in the DB.
User2 does the same.

User1 updates row 9 in the db and the information is saved.
User2 updates row 100 in the db and saves the changes.

Does row 9 from User2 (the original row 9) replace the changes that User1
made? or will only the specific changes in that dataset be posted back to
the server?

As you can tell I'm new at this and a bit confused.

Thank you very much..

[Nick Malik]

You have two excellent responses so far.

I just want to add one thing:

SQL Server has a column called a timestamp. It's an odd name, because it
does NOT store a datetime value. It stores a number that is automatically
updated to a clock count on the SQL Server EVERY time your row is updated.

If you have a table that you suspect a large number of people may be
updating, you will want to put a timestamp column into the table. That way,
you can select any row you want, update the data in your fields, and before
you update the row in the database, check to see if the timestamp column has
been changed. If it has changed, then someone else updated the same row,
and you should fail the update.

This may seem onerous. A user updates fields in a database row, clicks
Update, and gets an error message. If the collisions are rare, this isn't a
problem. In the past, I would have the Data Layer automatically select the
updated row, and my U/I layer would compare the fields between the data row
and the visible fields. If there is a difference, a window would appear
showing the values from the database along with an error explaining the
issue. The user could choose to overwrite the other person's changes,
whereupon the U/I would overwrite values into the data layer and call
..Update again, or the user would accept the differences. If there are no
differences (in other words, if two users made the exact same update at the
exact same time... it could happen), then I don't issue an error message.

As one of the other responders pointed out, the SQL generated by the data
adapter will automatically check every field (you can turn this off in the
data adapter wizard if you want). You can update that SQL to tell it to
only check the timestamp column, assuming you have added one.

If you have a high liklihood that two users will try to update the same row,
then I'd suggest adding a little "workflow" to your application. A user has
to indicate that they want to edit the row. When they do, your app calls a
stored proc with the user id as a parameter, and you store the userid in the
row to indicate that it is Checked Out (remember to check the timestamp to
make sure someone else didn't already check it out!). If another user has
checked it out, put an unobtrusive message or indication in your form and
you user will move on. If not, your user gets the record and an edit form
appears. This way, you can be fairly sure that no one else is editing the
row at the same time. You still need to check the timestamp when you store
updates, but you will get very very few hits, if any. (that would be an
interesting test case for your code, though).

Also, this way, you can have the row "remember" the id of the last user to
modify it, or you can keep a log of users who have checked out the row as
records in an associated table... lots of useful things.

I hope this helps.
Good Luck,
--- Nick
"Tc" <[e-mail] > wrote in message
news:ui******** **************@ news.easynews.c om...

Hi,

I was curious, I am thinking of writing an application that loads a dataset from a database that resides on a server. The question I have is this, if
multiple copies of the app will be running at once will there be problems
with data updates?

The reason I ask is I'm thinking like this:

User1 launches the app and the dataset is created from the data in the DB.
User2 does the same.

User1 updates row 9 in the db and the information is saved.
User2 updates row 100 in the db and saves the changes.

Does row 9 from User2 (the original row 9) replace the changes that User1
made? or will only the specific changes in that dataset be posted back to
the server?

As you can tell I'm new at this and a bit confused.

Thank you very much..