File locking / sempahore necessary in multi user environment?

Scott Bryce

I am creating a CGI application in Perl that uses an Access database. It
will be hosted on an NT server. I have used flat file DBMs (tied hashes)
on UNIX servers, but I am not familiar with how Access behaves in a
multi-user environment.

Will I need to use some sort of file locking/semaphore scheme, or does
Access (or the ODBC drivers?) manage conflicts between multiple users? I
want to avoid corruption of data should multiple users attempt to write
to a table/record at the same time.

If a semaphore is not normally needed, under what circumstances should I
consider using one?

Nov 12 '05 #1

Scott McDaniel

Access will handle the file locking internally. The locking scheme is, of
course, dependant on how you setup Access/Jet and what parameters you set on
your connection objects (ie. adLockPessimistic, adLockOptimistic, etc), what
type of recordset (if any) you open, etc etc.

How heavy will the transaction load be? Access works fine in a Web
environment assuming most of your processes are analytical (i.e. lookup,
reporting, etc). If you are going to be doing a LOT of transactions, backup
frequently.
--
Scott McDaniel
CS Computer Software
Visual Basic - Access - Sql Server - ASP
"Scott Bryce" <sb****@singlepoint.net> wrote in message
news:3F**************@singlepoint.net...

I am creating a CGI application in Perl that uses an Access database. It
will be hosted on an NT server. I have used flat file DBMs (tied hashes)
on UNIX servers, but I am not familiar with how Access behaves in a
multi-user environment.

Will I need to use some sort of file locking/semaphore scheme, or does
Access (or the ODBC drivers?) manage conflicts between multiple users? I
want to avoid corruption of data should multiple users attempt to write
to a table/record at the same time.

If a semaphore is not normally needed, under what circumstances should I
consider using one?

Nov 12 '05 #2

Scott Bryce

Scott McDaniel wrote:

Access will handle the file locking internally. The locking scheme is, of
course, dependant on how you setup Access/Jet and what parameters you set on
your connection objects (ie. adLockPessimistic, adLockOptimistic, etc), what
type of recordset (if any) you open, etc etc.
Not being familiar with Access, I don't know how to set all of that up.
I suppose you are not familiar enough with the Perl DBI to offer any clues?
How heavy will the transaction load be?
At least several hundred new records every day. Possibly several
thousand. Probably not as many as 10,000 new records every day. New
records will be purged periodically and the information will be used to
generate printable reports. (Or is it better to retain the information
and flag it as "deleted" in case of data loss requiring the reports to
be re-generated?)

If you are going to be doing a LOT of transactions, backup
frequently.

What is a lot? If the data is purged several times a day, will the
backups be useful? How often is frequently?

Nov 12 '05 #3