Daniel Kasak wrote:
Andrew Jensen wrote:
There seems to be a similar problem when using MS Access with Base. A
number of users from the Base forum have reported the following problem.
Currently there is an ASP application that connects to an MSA
database. Base was used to connect to the same MSA database. When the
Base file is open the database is locked, causing the ASP connection
to fail. In both cases that where reported they are using ODBC to
make the connection. I am wondering if there is some way ADO could be
used instead that would allow Base to open the mdb file without a
full lock?
To be honest, you really shouldn't be using MS Access to store data in
a multi-user environment. Access is good for creating a GUI to connect
to a real database server, but using Access as the 'server' is begging
for trouble.
What I suspect is happening here ( I haven't tested this ) is that
Base is creating a *filesystem* lock to access the mdb file. Access
uses a 'record locking file' ( .ldb ) to indicate who's accessing
what, but then everybody needs read/write access ... simultaneously
... to both the mdb and ldb ... for this to work. It doesn't work.
Daniel,
Thanks for the information.
Well, it isn't my application. This came via the Base list at OOOForum.
As of the moment no one has responded to offer these guys any help, and
I have been doing a little experimenting.
Creating a Base file that connects to a mdb file by selecting a
conection type of MS Access via the Base wizard opens the file in
sharedDenyNone mode. ODBC and ADO also default to this mode. I can
indeed create multiple Base files all hitting the same mdb file and work
in them simulaneously with no problem, if you discount the lack of
record locking. More on that in another post, later.
Anyway, what I suspect is happening with these users is this. The web
application, using ASP is trying to open the mdb file in exclusive mode,
but not holding the connection open. Doing a little research via google,
this seems to be a used technique ( but that is a guess on my part ).
Now if the user opens a Base file, which opens a connection in shared
mode and holds it open. The ASP application will then fail on it's next
attempt, as it must. The problem is the users are perceiving this as the
fault of Base, in fact if I take one of my ADO connection Base files and
change it to open in excluse mode, then open one of the sharedDenyNone
mode Base files first the attempt to connect in exclusive mode fails -
the error message is misleading however - it tells me that the file is
already opened in exclusive mode, when what is really happening is that
it is open in a mode that denies the ability to get an exclusive lock on
the file. Like I say though, that is just confecture at this point. I
will pose the thought to the users have them check.
As for MS Jet not being suitable for multiple users...well, sorry I
can't agree with you there. VB / Jet and a couple of dozen users was not
a problem. MS Access using multiple mdb files with the data on the
server and the UI objects on client machines worked also - or at least
it did back in the day when I built that kind of thing...of course that
was a long time ago....they say we only remember the our successes and
forget the failers. Then again it would not be my first choice when
someone says - concurrent multiple user database application, either. :-D
As an aside, there is another user from the Forum that I did help a
while back - he converted his office to an OO front end and kept the MDB
file for the datasource. Interestingly enough he opted not to use Base,
per se, for the data entry portion. Instead he went with a Calc file,
where each sheet simply holds a different data entry form, ( as I recall
9 or 10 forms) that way it looks like a huge multi tabbed or MDI
applucation. He has a half dozen staff doing data etnry and a Base file
with some canned reports for management. Last I head he was having no
prbolems with the concurrent connections.
Drew
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
