Transactions and concurrency

[Michael Weber]

Hi.

I was wondering how Access ( 2000 an onworth) are handling
concurrency issues when performing transactions.
( If I am in the wrong newsgroup please point me to the corrrect one.)


As I understand it, transactions are performed in-cache which to me suggests
f.ex. lost updates would be possible i.e. while some one is performing
a transaction someone else is, at the same time, updating the same
tuplet and this update would be overwritten if the latter transaction is
committed.

Example :

Initial tuplet value = 1

Client1 | Client2 Time
BeginTrans | T
.... | BeginTrans T+1
//adds 1 | ... T+2
update tuplet | //adds 1 T+3
.... | update tuplet T+4
Commit | ... T+5
| Commit T+6


Would tuplet value be 2 or 3 after Client2 commits?
And if tuplet value is 3 if both commits,
what if Client1 rolls back ?

Now, if both commits and the value of the tuplet is 2, is it not then
misleading to offer a funtionality such as transactions when neglecting the
responsibility of assuring exclusive access to the tuplet whilst performing
a transaction ?

On a related note...
I have heard an uncomfirmed rumour that MS used parts from SQL Server
when developing Access. Is there any truth to that ?

A reference to a site that explains how Access handles
transactions would be much appreciated.
I have tried MSDN og Technet but haven´t been able to find anything.

Thanks in advance.

Best Regards
Michael Weber

 

[Evi]

Translation guide:
tuplet: any consecutive group of notes with an individual value more or less
than half as long as the next larger note value (???)
Concurrency: a property of systems in which several processes are executing
at the same time -
In-cache:
Cache: a collection of data duplicating original values stored elsewhere or
computed earlier

In brief, Mr Weber seems to be asking how Access handles a multi-user
enviroment and wants references to useful websites

A Google on the words Access multi-user environment will yield some
excellent results, Mr Weber.

Evi

 

[Ken Sheridan]

He's referring to a tuple. Of course I would not dream of suggesting that
you knew that already, and are being a little bit mischievous in
disingenuously suggesting a musical definition<G>. The use of the term
'tuple' is not really appropriate in this context, however. Relations have
tuples, tables have rows. Lets not go near the old chestnut of whether the
terms 'record' or 'field' are appropriate in the context of a table!

Actually tuplet does have a mathematical definition too: 'An entity or set
with a given number of elements, a vector.' (Shorter OED, 6th Edition).

As far as transactions are concerned my understanding is that Jet
accumulates locks and does not release them until the transaction is
committed or rolled back. Consequently another transaction encountering a
lock will generate the usual errors which can be handled in the normal way.

Ken Sheridan
Stafford, England