is using a DataSet dangerous?

  • Thread starter Thread starter Francois Malgreve
  • Start date Start date
F

Francois Malgreve

Hi all,

I may post a stupid question on the newsrgoup but I am quite beginner with
ADO.NET

Anyway I read in the various papers speaking about ADO.NET is that the
DataSet is a important new improvement as you can work on it disconected and
then keep a disconnected cached version. In the literature on ADO.NET
everybody speaks about DataSet as a new miracle and dismiss the old fashion
way to just run a command object (Command).

Fine BUT what about the following scenario?

Let say I work in a multhi threaded environment, then Thread 1 populates a
DataSet and play with it. In the meantime Thread 2 modify some data on the
DB. Of course the DataSet in Thread 1 won' be aware of it then then the data
encapsulated in the DataSet will represent a wrong state on the Database.

Actually I asssume that this scenario could happen in a mono threaded
application if some event or any kind of code update some data in the DB
that is cached by the DataSet, here again the DataSet will NOT reflect the
state of the DB.

Idem for an ASP application, if some page use a cached DataSet in the
Session or even in the Viewstate (whatever it implies for performace reason)
but an other user change some data from somewhere else, the DataSet cached
would not reflect the actual status of the DB.

Then what? Did I miss something? DataSet seems to be what everybody is
using. Also it brings a lot of functionalities but if what I say is what
actually happen I cannot afford to use it eing afraid that it would bring
bugs as ny cached version of my rows may not reflect the actual state of the
DB. But in that case I would miss all the functionalities of the DataSet.

I could also use a DataSet as a Reader and dismiss it after i use it just to
be able to benefit its functionalities (but DataSet seems to be an expensive
object to keep being populated).

My main concern is that having 2 "versions" of my records (one in the DB and
one in the DataSet) make me things that many inconsistencies may happen...

Actually I would like to get back any comments on what I said, plus I would
like to know "When to use a Dataset " but more important "when to NOT use a
Dataset".

Thank you.

your confused programmer,
Francois
 
Hi Francois,

What you are describing is called concurrency.
Yes, it poses problems sometimes.
However, this was no left behind in ado.net.
Check out the whole chapter
Concurrency Control in ADO.NET
in .net help files.
Basically, when DataSet is updated against database the SQL stataments
(should) check if the original values of rows (or timestamp or whatever you
choose) are identical to those in database - if not - there is concurrency
problem. From here you have some options (described in help files).

What is the best approach really depends on you and on the nature of the
problem.
Btw, you'll have the same problem even if you use datareader or some other
technique - always some time elapses from reading -> updating.
The only solution would be to use FOR UPDATE select statament when reading
records.
But in this case you would lock records for everybody.
Imagine a person reading a table in this way, leaving the app open and going
to lunch.
Everything stops - nobody can update records anymore. Ouch.
 
thank you,

this is very useful information about concurrency problems. But it does not
really give me any guideline on the pros and cons on using DataSet. Like in
what scenarios should I use a DataSet and in what scenarios i should just
use a simple Command object ?
I would like some guidelines to help help me.

Any reference to such guidelines?

Thanks again

Francois
 
Hi,

Francois Malgreve said:
thank you,

this is very useful information about concurrency problems. But it does not
really give me any guideline on the pros and cons on using DataSet. Like in
what scenarios should I use a DataSet and in what scenarios i should just
use a simple Command object ?
I would like some guidelines to help help me.

Any reference to such guidelines?
Click to expand...

I don't have any guideliness, though I do the following.
If I have a business operation, I manipulate the DataSet and save all of it
at the end.
If I need a SQL statament to update/insert/delete many rows in database
without my program interaction I fire a command.
Again, I don't think that there are any guideliness - use your common sense
now that you know the shortcommings of both sides - it is up to you.
 
ok. I think I should use the DataSet when I may use its functionalities at
my benefits, if not i assume just creating a Command object and execute it
is enough.

thanks for your help, I think I just confused myself. Now I think I am back
on tracks;)

Anyway if i have a specific problem i will come back to the newsgroup.

thanks again

francois
 
ok. I think I should use the DataSet when I may use its functionalities at
my benefits, if not i assume just creating a Command object and execute it
is enough.
Click to expand...

Yes, something like that :)
thanks for your help, I think I just confused myself. Now I think I am back
on tracks;)
:)

Anyway if i have a specific problem i will come back to the newsgroup.
Click to expand...

No prob.
 
There aren't really guidelines, it depends on what you want to do. It's
actually rather simple.

If you only need forward-only read-only access to the data then use a
DataReader.

In all other cases, use DataAdapters & DataSets.

In your messages, you never mentioned the DataAdapter (maybe you haven't
read that far yet?). The DataAdapter is the object that actually goes and
gets your data from the database for you. It has within it 4 command object
(select, update, insert, delete). You mentioned just using a simple command
object, you could create your own or use the ones built into the
DataAdapter.

When you want your DataAdapter to go and get you your data, you call its
Fill() method, when you are ready to post your copy of the data back to the
original, you call its Update() method. The DataAdapter can handle many of
the concurrency issues that may come up automatically, so it's not as big of
a deal as you may think.

Lastly, in your messages, you motioned having the disconnected set of data
cached. While it is possible to do this, I want to clarify that this is not
automatic. It seemed from your original message that you thought that
DataSets are automatically cached. This is not true, they are a copy, but
that copy is not cached automatically.
 
Use two datasets on each thread, one to modify and one read only.
Just before the database is updated, compare it with the read only dataset.
If there are changes, alert the user and let him/her decide what to do, keep
the data in the database or update it with its own.

rg,
Eric
 
Back
Top