File Not Fount

[bloop]

Hello Group,

I set up filemaker file sharing between 2 computers which uses a script that I call Opener.fp7. What this script does is to open a specified hosted file & then immediately closes itself, leaving the hosted file open on the client machine. I set the file options on the client machine to run this script automatically when the Opener file is opened. The problem with this method is that one specific machine must serve as the host & have the database opened first. I would prefer to have the script search to see if the main file is open & if so to continue running this script, if not to open the main file.

If there is no solution to this problem, I would like to have the script send a message that the file is not open & to open it “directly” & to quit.

Thanks in advance,

Geo.

[Matthew F]

I set up filemaker file sharing between 2 computers which uses a script that I call Opener.fp7. What this script does is to open a specified hosted file & then immediately closes itself, leaving the hosted file open on the client machine

I assume that you mean that you have a small FMP file named 'Opener.fp7' that has File Options set to run a script when it is opened. This script attempts to open a remotely hosted database and then closes the local 'Opener.fp7' file.

There are several approaches you can take in the following order according to speed and reliability:

1. Plunk down the big money and buy Filemaker Server and have it run your databases on a dedicated machine.

2. Put your databases on a dedicated machine but host them with Filemaker Pro. Keep the program running and don't let anyone logout the current user.

3. Put your databases on a 'always on' server (like a Unix box). Let users log on to the server and launch the files. The first person to do so becomes the host. Other users can join in by becoming clients to the host. When the host closes the databases the clients will be forced to quit as well.

4. Put you database on one computer and have it be an intermittent host if the database is in use. If it is not being hosted but the machine is still on others can log on and launch the file directly. The first one to do so becomes the host. Others can access the files remotely from this host but will be forced to quit if the host closes the database.

It seems like you're trying to do option #4. You can automate this process somewhat in the script that runs in your Opener file with a series of steps such as these, assuming you're using Mac OS:

Set error capture [on]

Open file ["remote file reference"]

Set variable [$err; Value:Get (LastError)]

Set Error Capture [off]

if [$err = 100]

Perform Applescript["mount volume "afp://user:[email protected]. address/Volume""]

Open File["mounted file reference"]

end if

### End

There is a security risk to this approach because the host computer password is coded into the 'perform applescript' step. You might want to remove user privileges to view and modify the script.

You will also need to define two file references. One for the database when it is being hosted by the remote server (remote file reference) and a second file reference when it is to be launched directly over a mounted server (mounted file reference). You will need to add more if() statements and file references if others might be hosting the database.

Unless you have a limited number of computers participating and their IP addresses never change it will probably be more practical just to teach the users how to log on without resorting to an automated approach.

[bloop]

Thanks mfero,

I'm going to try #4. There are only 2 Macs involved & my friend will surely not agree to spending more money on a server.

Thanks again for the response.

Geo.

[IdealData]

Please be aware this is a dangerous practise.

You are (in one instance) opening the file on a remote machine. There are several issues, not least of which you should note the following:

1. Performance is crippled when you are hosting remotely

2. The file can still be opened DIRECTLY even if it is being hosted

Avoid these points at your peril!

[bloop]

Please be aware this is a dangerous practise.

You are (in one instance) opening the file on a remote machine. There are several issues, not least of which you should note the following:

1. Performance is crippled when you are hosting remotely

2. The file can still be opened DIRECTLY even if it is being hosted

Avoid these points at your peril!

Thanks for the message, IdealData but I must admit that I'm a little confused by it, could you further explain ?

Thanks

[IdealData]

Quite simple really - don't do it, otherwise you may damage your files.

[Matthew F]

I agree that 'option 4' is the most risky way to share files. No matter how you share files be sure to have an automated backup system.

If you have an extra seat license for filemaker another option (in Mac OS X) is to create a dedicated User in the System Preferences on the host computer (e.g. 'Filemaker Host'). Logon to that User, launch the file and activate sharing within filemaker. Do not ever logout this user. Instead use 'Fast User Switching' to login as a regular User account and access the database with Open...Remote within Filemaker. The advantage is that a user of the host machine can logout without fear of shutting down the database while its in use by others.