Remove MsgBox "...opened read-only..." at startup? 3

[balor]

Hi,

if you write protect an .adp or .ade file you get a warning message when you open it: "The database xxx will be opened read-only...".

Can I remove that warning message?

Is't wery confusing! The user realy think that the DATABASE is read only when it's only the klient that is read-only.

//Balor

 

[Steve101]

Balor,

I have the same problem. Did you get any resolution to this. If so, I'd appreciate it if you could advise.

Thanks


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

 

[EriRobert]

Balor,

Not much use I know but I too would like a solution to this. In my case our users often minimise the application, forget and then reenter the application again. In this situation you get the same message as you described. I have put some code in the application to detect if the same application is already running and throw them out if it is (politely), but you get that annoying techy message first which the users don't understand and call us.

So - someone solve this!

 

[neecie]

I am afraid I have bad news...
Microsoft says this behavior is by design (see MSKB article 322762).

 

[BobJacksonNCI]

FWIW - Near the end of MSKB article 322762, it states:

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

 

[Steve101]

Thanks for the input guys; dumb design decision by Microsoft if I might say; especially with the ADE, which by definition is read only.

Cheers,
Steve

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

 

[drctx]

i just ran into this problem this morning. what a dumb design.

 

[transmat]

Quick and simple solution - run it on terminal server and set up separate directories for each user, with each directory containing the client (ade file). Then create shortcuts by user pointing to their area on the terminal server. Downside is additional memory taken up on the server.

 

[juddm]

Just an idea - I updated to office (2000) sp3 and this is fixed......

 

[Steve101]

juddm,

I've just tried the sp3 update, but alas it does not seem to fix the problem in my case. I still get the same message. Are you aware of additional command line options? Can you please confirm that you're able to instantiate 2 copies of the same adp or same ade without getting the message.

Cheers,


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

 

[BobJacksonNCI]

Since I posted to this thread before, I feel a responsibility (admittedly minute) to see it through.

The Microsoft idea is to allow varying capabilities in forms and reports (front end) by user. So, the design is to give each user their own .ADP/.ADE. When you do that with the appropriate shortcut so only one user accesses a given .ADP/.ADE, they won't receive a read-only message.

Note there are threads here in Tek-Tips illustrating methods to roll out new versions of files.

Reference the following two Microsoft Knowledgebase articles:

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

-------------------------------------------------------

322762-ACC2000: "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 2000

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

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

For a Microsoft Access 2002 version of this article, see 318868.

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

 

[bbrendan]

see this thread

thread958-619535 reason is that more than one person is accessing the adp at the same time. You need to make local copies to the users computer.

hth

 

[rr191]

I was able to eliminate the message by adding the /runtime parameter to the command in the shortcut that I have deployed on each user's desk.

If I understand correctly, I now lose some error handling capabilities and now need to account for these errors in my code.

Does anyone know if there are any other issues I need to worry about? Thanks

-- Rob

 

[drctx]

what runtime parameter did you add to your shortcut? and where did you find information about this?

 

[rr191]

Here's what my shortcut looks like:
"C:\Program Files\Microsoft Office\Office10\MSACCESS.EXE" P:\OFFADMIN\VacAppXP.ADP /runtime

I found this information in "Access 2002 Enterprise Developer's Handbook" by Litwin, Getz and Gunderloy. I could not find it in any of the help topics in MS Access 2002.

-- Rob

 

[Steve101]

Well done Rob. This works a real treat, and sure as heck beats a lot of other 'explanations' provided by some others to justify that silly warning message. A well earned star in my keep it simple book.



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

 

[drctx]

Thanks Rob. works great.

 

[neecie]

You may have found a workaround to receiving the unwanted message, but depending on the work environment your application runs in, it may not be the best solution.
The following warnings are from MS regarding the use of the /runtime parameter:

[ul][li]"The /runtime option does not secure your application. Any user who wants to could remove the /runtime option from the shortcut or start Microsoft Access and access the design of your application's objects." [/li]
[li]"Your application must have a startup (switchboard) form that provides access to all objects." [/li]
[li]"Built-in toolbars are not supported."[/li]
[li]"Some windows, menus (including shortcut menus), and commands are hidden or disabled."[/li]
[li]"In the run-time environment, certain Access features are disabled and/or hidden from the user."[/li]
[li]"If no Access runtime licensing key is present in the Windows registry, your run-time application will not run."[/li]
[li]"Your application uses its own Help file."[/li][/ul]

If you have the developer's addition of office, you can test your app in the runtime environment. If not, you have no way of knowing how your application is going to respond to your users. I have used Microsoft products long enough to know that it is very unwise to give anything untested to users.
If you are going to use Access .adp projects, I would suggest, as many others have in this post, using it as it is intended to be used by creating local copies for each user. Otherwise you should use a standard .mdb file.

 

[Steve101]

Needcie,

You make some interesting points above, but do please note the following:

(a) I've tested the /runtime option with both an adp and ade client. In both case it worked without problem. With an ade, the design was secured and not alterable to the user, yet sharable.

(b) There was no switchboard in my application, and it worked with the interface that I provided, as expected.

(c) I hav'nt tested the ability to use built in toolbars etc. I'm sure you're right on this point, but perhaps you could provide a reference to the Microsoft material that you're referencing.

(d) It goes without say that you test the application before distribution.

(e) All of that being said, from a performance over the network point of view, the local client model is preferable anyway, but notwithstanding this, I'm yet to be convinced that a shared ade is not a 'safe' option, though I agree with (some of) your reasons for not promoting

Cheers,


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

 

[rr191]

Here's a short excerpt from the Access 2002 Enterprise Developer's Handbook that also lists some issues with using the runtime version of Access or the retail version of Access in runtime mode:

1. The database window is permanently hidden. (Because the database window is permanently hidden when executing under the Runtime version, it's important to have either a startup form or an Autoexec macro specified. Otherwise, your application's users will be left staring at an empty screen, with no way to open any objetcs.)
2. The Visual Basic Editor is permanently hidden.
3. All Design views are permanently hidden and cannot be used. Note in particular that the Filter by Form and Server Filter by form windows are considered Design views, so you can't use these modes in a Runtime application.
4. The built-in toolbars are unavailable, but you can still display custom toolbars.
5. Many commands (all those related to designing objects) are dropped from the menus and shortcut menus.
6. Any untrapped error is fatal and causes your application to exit without warning. This applies to any macro error and any error in VBA code that's not handled by your own error handler.

---
I think the biggest issue for developer's in item #6. As for the rest, it may or may not be beneficial to the developer to hide the Access menus from the user -- it would depend on the application and how it was designed to be used.

-- Rob