Locking an Access table

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi all,

For locking a record in a table I had to add a boolean column to the table
and toggle it when a user accesses that record.
Now I need to lock the table so users cannot access that table at all. Is
this possible in vb.net?
Thanks all for your input.

Roy
 
Hi Roy,

ado.net is based on optimistic concurrency and as it has no such methods.
Why would you need it anyway? Pesimistic concurrency is usually a bad idea.
 
What do you mean by "lock the table"? If you are using Access/Jet,
there is no way to prevent users from simply connecting to the mdb,
opening up the table using Access, Excel or any other software. If
that is not what you mean, please be more specific with your scenario.

--Mary
 
ado.net is based on optimistic concurrency and as it has no such methods.
Why would you need it anyway? Pesimistic concurrency is usually a bad idea.
Click to expand...
Really? Consider this scenario: I am working with one of my customers
data. Now someone else changes the last name of the customer, because
he/she married. Now: with optimistic locking you have the following
qustions:

- When is this change of last name determined in my application?
Usualy only when I commit my changes. In between there is a certain
time during that I have other state than the database. Should I not
make any changes, I never get it.
Whether this is important - I don't know. But should it turn out that
it is in a certain situation: its too late.

- Should it happen that two users happen to make changes to the same
data item then some strategy to resolve this is needed. "Last wins"
often is not what the user wants.

- In our application we want the user to see a visual clue that
someone else is currently working with the record.


Not all applications are stateless! Or Webapps!

Greetings - Martin
 
Martin,

Maybe is the problem that Miha and I live in countries where the changes
between married and unmarried goes not so quick. Therefore the change on an
concurrency error is probably not higher than 0,001 percent in the case of
your sample.

That is than the reason that in our situation it is possible to let the user
(who has the concurrency error) check if the last name is right, and than to
change it, or to let it as it is in the current situation.

This in your sample, in other situations with higher rates of changes, than
you have probably to take other actions (if it is about money or values like
that, than it is possible that you even need more information like the
original values to decide). However, this is how I would do it in this
sample married/unmarried sample of you.

By the way, your sample shows exactly what optimistic concurrency is based
on. "It will not happen that often and/or it can be corrected always
afterwards". There where that is not possible, you should take other
solutions.

Just my 2 eurocents,

Cor
 
Martin,

Maybe is the problem that Miha and I live in countries where the changes
between married and unmarried goes not so quick. Therefore the change on an
concurrency error is probably not higher than 0,001 percent in the case of
your sample.
Click to expand...
Maybe my example was not crafted properly. I tried to find something
drastic to show the effects. Of course, the change in surname is a
really seldom case. But we can afford to do pessimistic locking, and
even more, our customers seem to expect such behavior. Why should I
analyse arbitration strategies when I can avoid it?

It is just an answer to the statement "optimistic locking is neraly
always the better solution". I think not so.

Greetings - Martin
 
Back
Top