Database Opened Read Only Message

[Steve101]

I have created a multi user ADP application, and saved it as an ADE.

Is there any way that I can prevent the following message from appearing when the application is run:

"The database will be opened Read-Only because one of the following has occurred.

The file is locked for editing by another user, or the file or the folder in which it is located is marked as read only, or you specified that you want to open this file read only"

This error occurs event when I try to run an ADE file, which by definition is locked.

I note the following:

(a) No command line options seem to exist to allow me to do this. The /RO option in fact forces the message.

(b) I would prefer not to have to use a runtime version, though I understand that this might be the way to solve it.

(c) I also understand that making a local copy of the application on each workstation might also do the trick; whilst this can be automated, I'd also prefer to avoid this.

Anyone have any ideas on the best way to handle the above. Your input would be appreciated,

Cheers



Steve Lewy
Solutions Developer
steve@lewycomputing.com.au
(dont cut corners or you'll go round in circles)

 

[Norris68]

Check your users have read/write access to the shared area where the mde sits. Access will try to modify the mde file date when it is opened, even though implicitly you cannot change an mde database.

 

[Steve101]

thanks mate; no problem with the access; still get the message. The suggestion about updating to sp3 in thread958-507792 seems to be the way to go.
Cheers,

Steve Lewy
Solutions Developer
steve@lewycomputing.com.au
(dont cut corners or you'll go round in circles)

 

[BobJacksonNCI]

Steve,

Hope the following Microsoft Knowledgebase copy helps...

Bob

318868-ACC2002: "The Database Will Be Opened Read-Only" Error Message When Users Try to Open a Project or Extension File in a Multiuser Environment
The information in this article applies to: Microsoft Access 2002

This article was previously published under Q318868
This article applies only to a Microsoft Access project (.adp).

Moderate: Requires basic macro, coding, and interoperability skills.

For a Microsoft Access 2000 version of this article, see 322762.

SYMPTOMS
When users in a multiuser environment try to open a Microsoft Access project (.adp) file or a Microsoft Access project extension (.ade) file, they may receive an error message similar to the following:

The database DatabaseName will be opened read-only because one of the following occurred: The file is locked for editing by another user, or the file (or the folder in which it is located) is marked as read-only, or you specified that you wanted to open this file read-only.

CAUSE
This behavior is by design. An Access project is strictly a client and has no multiuser capability.

RESOLUTION
To resolve this issue, deploy a copy of the .adp file or .ade file to each computer.

For information about how to deploy Microsoft Access project solutions, browse to the following MSDN articles:
Developing Client/Server Solutions with Microsoft Access 2000 Projects

http://msdn.microsoft.com/library/en-us/dnapg/html/apgintro.asp

Creating and Deploying Access Solutions with the Microsoft Data Engine

http://msdn.microsoft.com/library/en-us/dnacc2k/html/msdedeploy.asp

 

[birgitd]

One of the biggest issues I see with people going from an Access Database to an Access Project is that they want to treat the files the same. With the database, everybody HAD to log into the same file, since that is where the data was. In a Project, the data is not local, and there is absolutely no reason for multiple people to use the same file. Each person should have their own local copy of the application, all pointing to the same data source.

I have about 40 users currently for the Access project that I developed. I keep the most current version of the .ADP file on a file-server (my development copy is stored elsewhere), and all users have a batch job that runs at login that copies the file over from the file-server to their local machine. They then have a shortcut on their desktop that points to the local file. This has been a great solution, since I can put new copies out and they are automatically "distributed" when the user logs in. If there are critical updates, users can log off/log on (or manually run the batch job), and they're back to work.

Hope this helps (sometimes those MSDN articles are a bit dry).

Birgit

 

[Steve101]

Bob, Birgit

thanks both for your help. Much appreciated. Unfortunately you've both confirmed that what I want to do is not possible without the nasty little message (sigh!), and it looks like I may have to opt for the local copy approach, which is no big deal, but I would have hoped to avoid it if possible - I'm operating on an efficient and well behaved network, so I had'nt anticipated a shared client as being a problem.

Birgit, just a small correction to your post. You state:

".... With the database, everybody HAD to log into the same file, since that is where the data was....."

Actually this is not the case. A well constructed application will always split the data (ie. tables) from the other objects, and use linked (attached) tables to connect the two. This allows data and program separation.

Since Microsoft allow a shared client in an MDB environment (where locking occurs at an object level should two users attempt to change the design of the same object), their treatment of the ADP environment is inconsistent with this approach (apparently by design, but nevertheless, inconsistent). For ade files, it is particularly difficult to understand why sharing cannot be achieved without a warning.

Ah well, such is life ....

Cheers again,



Steve Lewy
Solutions Developer
steve@lewycomputing.com.au
(dont cut corners or you'll go round in circles)

 

[BobJacksonNCI]

Steve and Birgit,

Thanks for posting! This information helps all of us gain greater understanding. And, Steve, your latest points are well taken.

What if...

What if you have an application that is intended for a varied audience. I.E., maybe department managers are to have forms and/or reports that are not to be viewed by clerks, for example. Individual ADP/ADE deployment allows this easily without digging into workgroup security and programming tailored to who the user is.

Just a thought,
Bob