Exclusive access problem in split db

Brian K.

I've read several posts on this problem, since it's happening to me
right now. Can't seem to get rid of this. Using A2K2 on a large XP
network. PC front ends linked to a backend on a shared folder on
server. Things worked great for a while (couple of months), and then
last month I suddenly lost the ability to make changes to forms or
code, getting the exclusive access warning. This happens even when no
one is on the backend through their own front end.

The problem started when I was playing around with some posted
techniques to speed up a slow opening problem when more than one user
was using the back end. One technique involved opening up a dummy
form linked to a dummy table with one record and not closing it. So
in the backend I have tblDummyKeepOpen with one field and one record
with the number 1 in it. In the frontend I have a form frmKeepOpen
bound to this table. In the open event of my opening form I have this
code:

DoCmd.OpenForm "frmKeepOpen", acNormal, , , , acHidden

Unfortunately, I think I went overboard and also used the form
frmKeepOpen to open up a recordset based on the same table it's bound
to:

Public rsAlwaysOpen As Recordset
Public db As Database
Private Sub Form_Close()
rsAlwaysOpen.Close
Set rsAlwaysOpen = Nothing
End Sub

Private Sub Form_Open(Cancel As Integer)
Set db = OpenDatabase("M:\TimberDBWach_be.mdb", False)
Set rsAlwaysOpen = db.OpenRecordset("tblDummyKeepOpen")
End Sub
Now, of course at this point I can't get rid of this to see if it's
the problem, since I can't do anything. Except I can build new
queries and edit existing ones. Can't touch tables or forms.

So, do you think my problem could be associated with this persistent
form? How should I go about trying to get rid of it and start over?

Thanks for any help

Mar 19 '07 #1

engles

On Mar 19, 8:45 am, "Brian K." <brian_kee...@yahoo.comwrote:

I've read several posts on this problem, since it's happening to me
right now. Can't seem to get rid of this. Using A2K2 on a large XP
network. PC front ends linked to a backend on a shared folder on
server. Things worked great for a while (couple of months), and then
last month I suddenly lost the ability to make changes to forms or
code, getting the exclusive access warning. This happens even when no
one is on the backend through their own front end.

The problem started when I was playing around with some posted
techniques to speed up a slow opening problem when more than one user
was using the back end. One technique involved opening up a dummy
form linked to a dummy table with one record and not closing it. So
in the backend I have tblDummyKeepOpen with one field and one record
with the number 1 in it. In the frontend I have a form frmKeepOpen
bound to this table. In the open event of my opening form I have this
code:

DoCmd.OpenForm "frmKeepOpen", acNormal, , , , acHidden

Unfortunately, I think I went overboard and also used the form
frmKeepOpen to open up a recordset based on the same table it's bound
to:

Public rsAlwaysOpen As Recordset
Public db As Database

Private Sub Form_Close()
rsAlwaysOpen.Close
Set rsAlwaysOpen = Nothing
End Sub

Private Sub Form_Open(Cancel As Integer)
Set db = OpenDatabase("M:\TimberDBWach_be.mdb", False)
Set rsAlwaysOpen = db.OpenRecordset("tblDummyKeepOpen")
End Sub

Now, of course at this point I can't get rid of this to see if it's
the problem, since I can't do anything. Except I can build new
queries and edit existing ones. Can't touch tables or forms.

So, do you think my problem could be associated with this persistent
form? How should I go about trying to get rid of it and start over?

Thanks for any help

I'm not sure what you are trying to do with this technique. I've
never had to do that sort of thing with split databases. Anyway, a
couple thoughts:
1) Why is tblDummyKeepOpen in the backend?
2) It sure sounds like Access thinks you have an mde file. Real dumb
question - do you?
3) When this sort of thing (well, let's just say "odd" things) happen,
I decompile the application. Quite often helps.
4) If that does not help, then start a new database and import
everything (maybe except that one form).

Anyway, just some thoughts. Good luck.

Mar 20 '07 #2

Brian K.

The /decompile did not solve the problem, but something you said
triggered a thought.

My problem was that I couldn't get in and change anything, or so I
thought. I was able to remove the opening form from the startup
options. Once that was gone, I could then edit things as normal.

Turns out my hunch about trying to solve the performance problem two
ways at once was right -- there was an incompatibility. I got rid of
the code that opened the recordset, kept the form bound to the backend
table, and the problem went away.

The idea came from the Access Performance FAQ that I found through
this forum.

Thanks for your help.

Mar 20 '07 #3