Data Concurrency without DataAdapter

[Bhavtosh]

hello,

are there ways to handle concurrency without using data adapter? i could use
custom data classes that updates data both as a single record or in bulk but
how to handle concurrency issues is a point here.

my intention is not use dataset at all and use my custom data classes to
carry data across from UI to DB

pls share your ideas as to suggest

 

[William Vaughn \(MVP\)]

The industry has been handling concurrency issues for decades before the
DataAdapter (or TableAdapter). If your updates are simple (many aren't), you
can write a stored procedure (or ad hoc query) to execute the UPDATE
statement and capture the exception, RETURN value, RAISERROR or just the
Rows Affected value and work from there. I, for one, recommend approaches
where concurrency issues rarely come up. By designing in concurrency you
avoid collisions where more than one client tries to update the same row at
the same time. Too many applications design their applications by
positioning ambulances at the intersections instead of putting in bridges or
traffic lights.

--
__________________________________________________________________________
William R. Vaughn
President and Founder Beta V Corporation
Author, Mentor, Dad, Grandpa
Microsoft MVP
(425) 556-9205 (Pacific time)
Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition)
http://betav.com http://betav.com/blog/billva
____________________________________________________________________________________________

 

[Mary Chipman [MSFT]]

A lot depends on the database you are using (Access? SQL Server?
other?) and how you are accessing data. Are your data classes mapping
to stored procedures? Views? Direct SQL statements? How are you
handling form state? What kind of application are you building? Web?
Windows? What is your front-end? DataAdapter handles many of the
plumbing issues for you which you will otherwise need to code
yourself. There are a lot of choices. I'd recommend doing more
research or searching for solutions that other people have built and
shared that you can adapt to your needs.

--Mary

 

[Miro]

William,

can you give a simple example of 1 vs the other?
"Designing in concurrency"
in reference to "ambulances" vs "bridges and traffic lights".

I was under the impression ( im a newbie still with database on a multi user
system )...that you either dont check concurrency, or you get an exception
error if your datarow that you changed has changed since you touched - and
you code around it to warn the user or change the columns effected or such.

Or is your "design" in reference that you always somehow grab the latest
data for the user at the latest possible moment for them to 'change' the
data, and save the data?

-Just curious

Thanks,

Miro

 

[Bhavtosh]

yes, as to marry's point i question here is to know other ways then DA; of
course one can code custom classes for CRUD and also design DB in a manner to
respond to such situations so here i would like to know can we apply other
ways of doing so

 

[Jesús]

One way to handle concurrency at the client side is "optimistic concurrency
control". Optimistic concurrency control is the technique used in data
adapters. I don't see why you cannot or you don't want to handle concurrency
in the same way.

Optimistic concurrency control detects concurrency conflicts. A concurrency
conflict occurs when updating or deleting a row if that row was modified by
another user since it was read.

To detect concurrency conflicts you include field original values (the
values you read) in the where clause of update and delete commands. Here you
have several options:

(1) Include original values of all fields. (Applies to update and delete)
(2) Include original values of changed fields and original value of the
primary key. (Applies only to update)
(4) Include original values of a row version colum and the primary key.
(Applies to update and delete)
(5) Include just the primary key. (no "mofidied by another user concurrency
conflicts" are detected )


If the delete or update command affect no rows, there is a concurrency
conflict: the row was deleted or modified by another user since you read it.

Regards

Jesús López

 

[Mary Chipman [MSFT]]

Bhavtosh, the subject is too broad to be addressed in a newsgroup
thread -- you'll need to do some research on your own to find out the
best way to handle data access given your unique situation. No two
database solutions are alike; each one has an almost infinite number
variables that are all contingent on business needs, available
hardware and software, and developer expertise. There is no "one size
fits all" solution, although you can certainly determine best
practices for a given data access stack once you've determined the
optimal path for your situation.

--Mary