Form: this recordset is not updateable

Following a period of use with no problems, the access forms that myself and
colleagues use to edit data are intermittantly freezing with the message
"this recordset is not updateable." This occurs seemingly at random, and has
not been preceded by any changes to underlying tables, links, or
relationships. Fields are being edited successfully for some time - and the
problem is not related to new or different fields being edited.
I have rectified this problem each time by overwriting the existing form
with a copy of a near duplicate from another database with identical fields,
and changing any incorrectly linked subform.
If anyone can help: I would obviously like some advice on how I can prevent
these inexplicable lock-ups in future, and any insight into how they have
arisen - I was half-thinking that it could be linked to user access
privileges within windows, as users migrated to a new usergroup - but then I
doubt that would have resulted in acess/editing of the dbs at all.

On Tue, 6 Dec 2005 07:43:04 -0800, "LMIU"
wrote:

Following a period of use with no problems, the access forms that myself and
colleagues use to edit data are intermittantly freezing with the message
"this recordset is not updateable." This occurs seemingly at random, and has
not been preceded by any changes to underlying tables, links, or
relationships. Fields are being edited successfully for some time - and the
problem is not related to new or different fields being edited.
I have rectified this problem each time by overwriting the existing form
with a copy of a near duplicate from another database with identical fields,
and changing any incorrectly linked subform.
If anyone can help: I would obviously like some advice on how I can prevent
these inexplicable lock-ups in future, and any insight into how they have
arisen - I was half-thinking that it could be linked to user access
privileges within windows, as users migrated to a new usergroup - but then I
doubt that would have resulted in acess/editing of the dbs at all.

You may have some subtle database corruption issues - have you tried
Compact and Repair?

Another possible issue: if this is a multiuser database, is it
properly split? I.e. each user should have their own copy of the
"frontend" (forms, queries, reports etc.) all linked to a shared
"backend". If you're all sharing the same unitary database you'll have
not only these lockups, but bad performance, update contention, and
more frequent database corruption.

John W. Vinson[MVP]

You may have some subtle database corruption issues - have you tried
Compact and Repair?

Another possible issue: if this is a multiuser database, is it
properly split? I.e. each user should have their own copy of the
"frontend" (forms, queries, reports etc.) all linked to a shared
"backend". If you're all sharing the same unitary database you'll have
not only these lockups, but bad performance, update contention, and
more frequent database corruption.

I have tried compact and repair to no avail.

Each user has an individual copy of the from that they are using and only
one user uses a particular form at any time. The date which they edit are
located in seperate databases, and some (intentionally) locked information
displayed on the form is derived from linked tables from another sharede
database.

My hunch is still that this may be related to permissions, or some
corruption of user priveleges in windows - at the same time that we began
having intermittant problems with data locking up in the forms, we have had
problems with (prevuiously fine) master sheets in excell not updating from
linked tables unless the linked tables themselves have been opened
previously. Also there have been messages when using documents on a network
that another user has modified the file: overwrite yes/no, when the file has
definitely not been opened by any other users. So, I'm guessing this might
have something to do with it, but I'm still clutching at straws!

On Wed, 7 Dec 2005 01:20:02 -0800, "LMIU"
wrote:

My hunch is still that this may be related to permissions, or some
corruption of user priveleges in windows

Quite possible! I've been having similar trouble on my own home-office
machine (finally solved by going into the Registry and tracking down
every reference to the Temp folder).

Users must have full read, write, create and delete access to the
folder containing each .mdb file that they will open for editing.

John W. Vinson[MVP]

I have begun having this same problem in a database, but it is a newly
created database and one that only I have had access to, so I don't think it
would be related to permissions in this case.

Up until yesterday the database was updateable through the form view, now it
just beeps when I try to enter new data. All fields are not locked and they
are enabled, and I have removed any other potential locks on the data.

Has anybody come across a solution to this? LMIU?

ebrwstr


"John Vinson" wrote:

On Wed, 7 Dec 2005 01:20:02 -0800, "LMIU"
wrote:

My hunch is still that this may be related to permissions, or some
corruption of user priveleges in windows

Quite possible! I've been having similar trouble on my own home-office
machine (finally solved by going into the Registry and tracking down
every reference to the Temp folder).

Users must have full read, write, create and delete access to the
folder containing each .mdb file that they will open for editing.

John W. Vinson[MVP]