Comments on Determining If A db Is Open (1 Viewer)

Micron

AWF VIP
Local time
Today, 07:54
Joined
Oct 20, 2018
Messages
3,476
I sure hope I didn't start something. The context of the original post was where an Excel user was opening an Access db via Automation to preview reports. Presumably they would print it or do something else if what they saw was satisfactory. In that scenario, the target db is the one that contains all the reports to be viewed, so it isn't a matter of "is Access running", nor do I think that it's important if anyone else has the db open because it's task oriented to the user. What I thought was pertinent in this case was to test if the specific db was already open by that user. My take on the original code is that after a user reviews a report, there is the potential to open the same db to view another one because the report name was a variable, as I recall. It seems to me that it is sufficient to limit the test to the user's own pc - in this case. If it remained open and the action on the Excel side was repeated, you don't want to reopen the same db.

Unfortunately it seems that while composing in this forum you can't always see the entire thread so I can't review my initial post right now to see how badly (or not) I communicated the scenario. The replies are illuminating and apply to a slightly different interpretation of the original question, but it is all good stuff and I'm grateful for the edification. Just know that if a debate continues, it's about testing in a different scenario, which is still a good thing in my mind as there are others who will be able to take something away from a good discussion, regardless of which scenario they happen to be concerned with.
 

isladogs

MVP / VIP
Local time
Today, 11:54
Joined
Jan 14, 2017
Messages
18,186
One specific comment, perhaps explaining a previously weak statement:
...When a permissions problem prevents you from CREATING a lock file in the appropriate folder and you would have been the only person in the DB at the time, you CANNOT create the file so MUST open the DB as Read-only.

OK valid point. Apologies for doubting you! ;)
Just tested that scenario on a folder with restricted permissions
As you stated, the file is then opened read only with no lock file and therefore with all code disabled
As currently written, my utility then incorrectly considers that to have been opened exclusively. In fact you can open as many read only copies of the database in that folder as you wish.
As I don't know of any way of detecting that an external database has been opened read only, I'll have to leave it as is.
At least its detected its open!

UPDATE:
Just did a further test on a new database to which I had denied write access but not actually opened.
The code still treats it as open exclusively. Ah well!

NOTE:
In case anyone is interested, the attached Word doc has a summary on how to detect various startup conditions in Access
 

Attachments

  • Code to check Startup Conditions in Access.docx
    17.7 KB · Views: 107
Last edited:

isladogs

MVP / VIP
Local time
Today, 11:54
Joined
Jan 14, 2017
Messages
18,186
I sure hope I didn't start something....
In that scenario, the target db is the one that contains all the reports to be viewed, so it isn't a matter of "is Access running", nor do I think that it's important if anyone else has the db open because it's task oriented to the user.

Hi Micron
You got me thinking anyway....:D
My intention was to write a general utility that anyone could use rather than one specific to your situation.
If the code was done from e.g. Excel, the purpose of the 'Is Access running' test is simple - if the answer is no then that test db isn't running. If the answer is yes, further tests are then done to determine whether that specific db is running and if so whether its running exclusively...
 
Last edited:

Users who are viewing this thread

Top Bottom