ARGH! Help Me! Please! Split Database problem...

T

TL

I have user-level security setup for my db, and the db is split. The forms
being opened are opened in Data Entry Mode - so none of the records in the
record source are seen or accessed by the users. However, when the users are
entering information into the first field and they attempt to move to the
next field, they get the following message:

Couldn't update; locked by user <username> on machine <MachineName>.

Something odd: the back end has a record locking file as well as the front
end...and it shouldn't. That is the whole point of splitting a database,
isn't it, so you can keep the users out of the tables? I recreated the
database and split it again, and it still shows the same people are in it as
are in the front end. I am at a total loss and can't help feeling that these
two issues are related or symptoms of one or the other.

Any help will be greatly appreciated.

Tiffany
 
J

John Vinson

I have user-level security setup for my db, and the db is split. The forms
being opened are opened in Data Entry Mode - so none of the records in the
record source are seen or accessed by the users. However, when the users are
entering information into the first field and they attempt to move to the
next field, they get the following message:

Couldn't update; locked by user <username> on machine <MachineName>.

Something odd: the back end has a record locking file as well as the front
end...and it shouldn't. That is the whole point of splitting a database,
isn't it, so you can keep the users out of the tables? I recreated the
database and split it again, and it still shows the same people are in it as
are in the front end. I am at a total loss and can't help feeling that these
two issues are related or symptoms of one or the other.

Any help will be greatly appreciated.

Tiffany
Click to expand...

No. The purpose of splitting is NOT to "keep users out of tables" -
users can't do *anything* with data unless they can get into the
tables, usually via queries or forms rather than directly.

My guess is that you have the backend defaulting to open Exclusively.
View its properties; it should default to shared access.

The backend WILL have a .ldb file; every user who links to the backend
from their open frontend will, of necessity, have an entry in this
file, to keep track of which records they're currently editing, in
order to prevent two users from inadvertantly editing the same record
at the same time. If your form is working correctly, there should be
no such errors with two users attempting to add *new* records at the
same time, though.

One question: are you having all the users share the same frontend? If
so... DON'T; each user should have their own copy of the frontend, on
their own machine.


John W. Vinson[MVP]
 
T

TL

Something I should have mentioned...We are running Access 97. Until my IT
department gets their head removed from their posterior we won't be upgrading
any time soon.

Clarification of my previous statement: It was my understanding that by
splitting a database, the user would not have to be kicked out of the
database in order to make changes to the tables located in the backend. My
backend will not allow me to make any changes at all if any users are in the
front end. Please see my comments below about the backend.

"My guess is that you have the backend defaulting to open Exclusively. View
its properties; it should default to shared access."

Unfortunately, your guess is incorrect. The Default Mode was the first
thing I checked. Both the back end and the front end are set to Shared Mode.
Also, there are no record locks on this database of any kind - not at the
form level and not in the Advanced Options at the database level. Also, the
form is still setup in Data Entry mode. So no currently existing records can
be viewed by the users.

"The backend WILL have a .ldb file; every user who links to the backend..."

This is not the first database I have split. The other databases I have
split are working fine, and the front end is the only database that shows a
..ldb file. The backends of these databases do not have an .ldb file and I am
able to make changes to the tables that are located in the backend.

"One question: are you having all the users share the same frontend?"

No. Each user has their own copy of the front end.

I am guessing I am back to square one unless I misunderstood part of your
email. I do appreciate your time and response. I have checked the
permissions for user-level security that are setup in the other databases
which are not experiencing this problem. It appears that the permissions are
the same as the database that I am having problems with. Is it possible that
my workgroup information file has been corrupted and is causing this error?
Both the frontend and backends have been compacted and repaired. I have even
tried recreating this database and it still gives the same "Couldn't
update..." error.

Any help is always greatly appreciated.

Tiffany

John Vinson wrote:

Tiffany

No. The purpose of splitting is NOT to "keep users out of tables" -
users can't do *anything* with data unless they can get into the
tables, usually via queries or forms rather than directly.

My guess is that you have the backend defaulting to open Exclusively.
View its properties; it should default to shared access.

The backend WILL have a .ldb file; every user who links to the backend
from their open frontend will, of necessity, have an entry in this
file, to keep track of which records they're currently editing, in
order to prevent two users from inadvertantly editing the same record
at the same time. If your form is working correctly, there should be
no such errors with two users attempting to add *new* records at the
same time, though.

One question: are you having all the users share the same frontend? If
so... DON'T; each user should have their own copy of the frontend, on
their own machine.


John W. Vinson[MVP]
 
Top