How to Open MultiUser Files on a Network Server

Keywords: 	 multiuser files Access MDB FM 1932 WinExec Error

Question:

I have a scenario where two (or more) workstations can open an Access MDB file on the network manually by double-clicking on the .MDB file on the server, without any problems, but when I try to do the same thing using WB97D, using RunIconWait, I get the 1932 error when the file was already open by one of them.
The 1932 error says "... the process can't access the file because || it is being used by..." [msg truncated]
My code looks like:
RunIconWait("M:\serapps\crystal.mdb", "") ;to run Access file
and/or (same error with a FileMaker Pro file):
RunIconWait("d:\fmfiles\times.fm", "") ;to run FileMaker Pro file

Additional Details:

The files above are setup as multiuser files.

The WB code runs fine if no other users are accessing the file.

You suggested downloading 98A, and trying again -- since the error msgs might be more informative. But I did that, and I'm still getting the 1932 Winexec error.

The MDB file is a form that I want multiple people to be able to update simultaneously. It is set up for multiuser access.

I also tried the same thing with a FileMaker Pro file, and got the same error.

Both Access and FileMaker Pro know how to handle multiple users accessing the same file and should take care of any clashes, which they do fine outside of WB.

I get the same error if the *.FM or *.MDB files are on my local workstation, where I can have the file open, and someone over the network could open the file on my PC manually OK, but WB can't handle it.

All ,y users are logged into the server outside of WB, and all are authenticated by one server (PDC).
Ideas?

Answer:

Not sure about this one. I suppose we have to examine the differences between double-clicking the file and running it from WinBatch.

By specifying the MBD file in the Run statement, it forces a lookup in the registry of various parameters. Run, RunWait, or RunShell do not do it exactly like Explorer does.

The ShellExecute statement will emulate explorer - but it does not have a WAIT parameter.

I would suggest poking in the registry under hkey_Classes_root for .MDB and seeing what file type it is associated with, then looking under that file type - still in the classes section under something like xxxxx/shell/open/command and seeing the command line there.

Then try to recreate the command line * with the access exe file in a RunWait statement. There may have been a parameter that was getting dropped.

Question (cont'd):

I tried your suggestion and looked for the open command in the registry and found...
C:\Program Files\Microsoft Office\Office\MSACCESS.EXE /NOSTARTUP "%1"

Then I used the string in the RunWait. Here is my test wbt file.
prog="C:\Program Files\Microsoft Office\Office\MSACCESS.EXE" app="m:\CirApps\Batch.mdb" RunWait("%prog%", "%app% /NOSTARTUP")
I started the app directly (without WBT) at one workstation and then ran the wbt test file above at mine, successfully opening the app. Now, the problem with this approach is that the program's path (i.e., msaccess) could be different across workstations. So this precludes having a clean, standard wbt file.
The ShellExectute worked okay also, but it doesn't have a WAIT, which is required.

Can you guys either make the RunWait work like Explorer or put a WAIT in the ShellExecute????

Answer (cont'd):

But there should be NO problem in telling where access is on each machine.
If you use msaccess.exe in the Run function, we will attempt to look it up in the registry.
Or you can use the reg functions to read the registry and determine the exact location of the msaccess file.
Because of the unreliability problems, I don't think ShellExecute will ever have a WAIT parameter. When writing the code for the ShellExecute function, we found that the wait parameter was unreliable on anything other than an EXE. (You can try the wait parameter on your MDB file, but it most likely won't wait, or will wait inconsistently.)
You can use the WinWaitClose function with ShellExecute, to make Winbatch wait for the program to finish.
Note, that if you are doing a RunIconWait, the iconized name of the program may not be the same as the title of the normal window. So you may need to Run the app as a normal window, do a WinIDGet on the window title, and then do a WinIconize, using the ID handle of the window as the window parameter in that function, as well as in the WinWaitClose function.
Also note that you often need to put a time delay in before the WinWaitClose, as it takes windows a few seconds to generate the title after the app is launched. So put TimeDelay(3) in before the WinWaitClose.
You could try making a shortcut on the desktop to the MDB file, and then using RunWait on the shortcut file. That might also work.
But using AppWaitClose("msaccess.exe") ought to also work without ever knowing where the real exe is hidden. With all these alternative methods available, something ought to work.

RESOLUTION:

After some more experimenting I came up with the following approach that works for me so far:

                prog="msaccess.exe"
                app="m:\CirApps\Batch.mdb /runtime /x macSoref"
                ShellExecute(prog,app,"",@NORMAL,"")
                If WinWaitExist("Batch",20)
                   WinWaitClose("Batch")
                Else
                   Message("","The Soref process did not run.")
                   exit
                Endif
                Message("","The operation completed sucessfully.")

The good thing is that the WinWaitExist will either wait the full time specified or return as soon as the app is exited. This approach works (1) if the app never ran, (2) if it runs and closes before the WinWaitExist wait time is expired, or (3) if it runs for a long time before exiting.

Article ID:   W13471

Filename:   1932 Winexec when Opening MultiUser Files on a Network.txt

File Created: 1999:04:15:16:54:14

Last Updated: 1999:04:15:16:54:14

	Domain
	Logon Issues
	Microsoft Client
	Novell Netware
	Server Configurations
	Services
	WhitePapers

Database Search

TechHome