Resolving Error 3086 - Database ran perfectly for 17 months

[MSingh]

Hi,

I have a strange situation where error 3086 has suddenly popped-up in a database that has been running perfectly for the past 17 months.

The database has been deployed split with the BE on the file server and FE on 4 workstations.
The application ran perfectly this morning, then around mid-day suddenly error 3086.

I understand error 3086: "Could not delete from specified tables. (Error 3086)"
but what could cause the sudden problem?

Your assistances would be appreciated.

Kind Regards,
Mohamed

[BenCasey]

Have a look here: http://office.microsoft.com/en-gb/acces ... 60256.aspx
and here: http://office.microsoft.com/en-gb/acces ... 96316.aspx
There is a possible solution here: http://www.access-programmers.co.uk/for ... p?t=167968

BTW have you googled for Error 3086?

[MSingh]

Hi Ben,

Thank you for replying. I have looked at your links, Many Thanks.

Yes, I first googled for Error 3086, but could not find a similar scenario where the application has been running daily for a several months then generates this error.
The application opens an "Alarm Zone" with reminders for the day, so I can understand that an action query (which is runs in-transaction) might be failing, but what I can't understand is the error showing up suddenly. Perhaps, it's a bug ?; maybe the client did not exit the application correctly ?; power-failure & a table is now Read-Only ?

I was hoping someone experienced a similar problem and found a solution.

Kind Regards,
Mohamed

[HansV]

Is the problem reproducible? Does it persist after quitting and restarting Access? After rebooting the PC?

[MSingh]

Hi Hans,
Yes, tried all of the above. Neither is their a .laccdb file.
If it was a problem with the design of the query itself, then this would have shown up a long time ago especially since all 4 users are running the same action query daily.
There is no problem with write permissions to the folder since a text file in the same folder can be edited from the same workstations where the FE's reside.

The following has emerged:
There are 2 other MS Access databases on the same server in different folders. These where deployed by an ex-employee, they are not split, but are multi-user.
(Both these databases are being re-developed but are in usage since they are mission-critical).
Both these (existing) databases have also gone into read-only mode.
I copied them into a new folder & they are now editable.
The folders wherein they originally resided had a .txt file which can be edited, so no folder permissions problems here either.

Kind Regards,
Mohamed

[HansV]

That might indicate network problems. Access is very sensitive to those.

[MSingh]

Hi Hans,
This is stranger:
I renamed the BE file on the server and it's perfect, not Read-Only | renamed it back to it's original name & it's back to Read-Only.
I imported all BE tables into a new database, this works perfectly | replaced the BE on the file server with the new database, it works perfectly | renamed the new database back to the old BE name (to avoid relinking each of the 4 users) and the BE is Read-Only again.
Is this a bug in Access ? or
could it be indicative of a permission being set on the BE file by the server administrator (ie. not on the folder but the actual MS Access BE file within the folder), the client suspects tampering by the server administrator?
Kind Regards,
Mohamed

[HansV]

It's very strange indeed that the problem appears to be dependent on the filename of the backend...
But why would the server administrator change those permissions?

[MSingh]

Hans,
Not sure - - perhaps it's not the place to make such a comment, but then again no names are being mentioned:
The server admin is out-sourced, there appears to be an estranged relationship after senior staff changes (the server admin wouldn't disclose passwords to the new staff).
But just to be clinical about the topic: So, it is possible that such a permission could be set on the file name ?
Kind Regards,
Mohamed

[HansV]

I'm not a network expert, but I suppose it's possible...