Opener Files

[Vaughan]

Problem:

I have a database shared over the network. Each time people want to use it, they have to either use the hosts button in the Open dialog box, or they login to the network volume on the server and double-click on the file's icon. Is there an easier way for people to use the shared database?

Answer:

Yes, there is a better way. Accessing shared databases by clicking on file icons is a particularly inefficient way of sharing databases. Instead, many people provide "opener files" that make the process easy and efficient.

An opener file is a small database whose sole task is to connect into the server, open the desired shared database, then close itself quietly. From the user

[spragueg]

You can make a single file that can open any file of your choice. If you configue it with IP and filenames. Any file on the server can be accessed. It does require applescript so this a mac only solution. I guess if you needed to you could do the same thing with VB Script on the PC.

1.Create fields

g_AppleScript_Source (global)

g_ServerIPNumber (global)

g_FileName (global)

g_Password (global) (optional) - leave this out if you want to avoid a security leak.

c_AppleScript_OpenServer (calculation see below)

2. Create Value Lists and apply them to the fileds in a layout.

ServerIPList (if you have more than one server)

FileList (if you have more than one file on your server)

3. Enter Global Applescript source into g_AppleScript_Source...

tell application "FileMaker Pro"

activate

getURL "FMP5://[password]@[serverIP]/[File]"

end tell

4. Set up c_AppleScript_OpenServer calculation using substitute function to replace tags with data from fields

Substitute(Substitute(Substitute(gAppleScript_OpenServer_Source, "[password]", g_Password), "[serverIP]", g_ServerIPNumber), "[File]", g_FileName)

5. Create a script with a "Perform AppleScript" step to execute the contents of the calculation and attach it to a button on your layout.

[ August 15, 2001: Message edited by: spragueg ]

[Kay]

I just sent the simplest opener file around the office for our daily timesheet database and my users are practically throwing a party. Thank you so much for these posts! Spit and polish are the simplest things but boy do they make the difference.

Kay

OK, someone actually came by and kissed my head while I was typing this. What else have you got?

[ August 30, 2001: Message edited by: kattatonic ]

[mikemccloskey]

This is a great tip - but once you create the file that automatically closes, how do you open it to edit the scripts, etc. I open it, it does it's thing and then closes. How do you get into it? thanks

[Anatoli]

Or pause the script for 2-5 seconds

[Vaughan]

...or right at the top put in

If [ Status(CurrentModifierKey) = 1 or Status(CurrentModifierKey) = 3]

Exit script

End If

..this will exit the script if the Shift (or Shift+CapsLock) key is held down. (Shift = 1, CapsLock = 2)

If you choose to include the Pause Script step, put it *before* the Allow User Abort [off] step otherwise there won't be a Cancel button to click on.

I'm tending to do both now: build in a pause AND the Shift key override.

[jgw]

What if you've got a situation where you need to have networked solutions installed in multiple locations and those networks are unknown to you as a developer. Is there a way to set it up without having knowledge of the network it will be installed on?

[dspires]

Open it via a relationship from another file.

[Jodin]

yes there is john, and we are working through it now. basically, it's all based on the fact that MacOS (natively) and Windows (with a registry hack) can parse URL's that begin with FMP5://. Using the "OpenURL" script step you can then ask the user to input the server's IP address and fire up the networked databases that way. i think the format of the URL is :

FMP5://serverIP@password/databasefile.fp5

the big issue for us at this point is dealing with the Windows registry hack. the MacOS parses the URL without a problem.

the other issue i've found is that if you open your database with the IP URL instead of the Hosts dialog and are doing development, pointers to external scripts store that IP, not the "Filename.fp5 *" that is so nice.

but beyond that we are excited by the possibility of using this in a smart launcher. the first time you run it it asks for your server's IP, besides that's it's transparent. yay!!

jodin

[Neil]

I'm just having a bit of trouble with this line...

if [ Status(CurrentModifierKey) = 1 or Status(CurrentModifierKey) = 3]

FM won't accept a line exactly like the above, stating that CurrentModifierKey is not a recognized Status Flag. I have tried replacing "CurrentModifierKey" with "Shift" but it still won't work.

I must be doing something wrong, but not knowing FM scripting that well, I'm not sure what it is...

[-Queue-]

Try adding an 's' to your Key(s).

[esteshk]

I make extensive use of opener files in my solutions and agree with all of Vaughan's recommendations except for one. In an environment where opener files are distributed to hundreds of client machines (in my organization I run 48 FileMaker Servers and over 3000 clients) I never have the opener password passed to the served database. If you do this, a password change on your served files would require redistributing your opener file to all of your clients. Instead, an embedded password opens the opener so that the user is still only prompted once for a password which opens the served file(s).

[BruceJ]

Neil said:

I'm just having a bit of trouble with this line...

if [ Status(CurrentModifierKey) = 1 or Status(CurrentModifierKey) = 3]

FM won't accept a line exactly like the above, stating that CurrentModifierKey is not a recognized Status Flag. I have tried replacing "CurrentModifierKey" with "Shift" but it still won't work.

It's syntax is actually Status(CurrentModifierKeys)

[Vaughan]

"... embedded password opens the opener so that the user is still only prompted once for a password which opens the served file(s)..."

I've gone even more minimal that that... no password in the opener file! (After all, there's nothing in it except a script: I don;t even have fields in opener files any more.) Users open the opener, the opener calls the hosted file, then *it* prompts for the password.

This makes the opener file extremely portable, and cuts maintenance right down.

Platform: / Version:

FileMaker Version:

[esteshk]

I think the "embedded" password in the opener file, that denies access to Scripts is an essential maintenance avoiding feature. Without it, a curious user could monkey around with the script or delete it inadvertently.

[Vaughan]

Possibly, but after five or so years of using them, the only problems I've ever had with opener files are from that have passwords in them: the password in the main file gets changed then the openers don't work (and it might be months before infrequent users call to find out what's happened).

I have *never* had a user fiddle with the opener file. That's probably because the opener file does it's thing then forces itself closed immediately afterwards, and doesn't allow the user to cancel the script. So users don't get a chance to fiddle with any settings. They'd have to know to hold down the modifier key at startup, or to open the file indirectly to stop the startup script from running. Most users just want to do their work and not fiddle.

[esteshk]

Perhaps I didn't explain myself well enough. The password "embedded" in the opener, which is set to use this password when opening, is unique to the opener, never needs to change and is not affected by a password change in the target files. That's the point. I use this protocol as a safeguard from a curious or mischievous user who might press the Esc key, thus circumventing the opener script and poking around where they don't belong. Has this ever happened to me? I don't know, I prevent it. Is it likely to happen? Admittedly no, but why take the chance in a solution as widespread and mission critical as mine. The bottom line here is that we agree completely as to the value of opener files. Finding the best way to implement them in a given solution is the key to success for the developer and the users he/she serves. Kudos to you Vaughan for bringing the issue to the forum.

[Vaughan]

OK I see... there is a default password set in the document (opener file) preferences. Yeah, that'd be OK as long as it wasn't the same as any used in the solution otherwise it might get a bit odd, not prompting for a password.

We agree!

[Ted S]

Hey folks,

I stumbled across this nifty tip in a magazine artice this morning. It looks like it could be a replacement for the opener file concept but there may be some reasons to stay with the opener file.

This works on Windows, for Macs I don't know.

1. Right click on your desktop and create a new shortcut.

2. Instead of browsing to a file location enter: FMP5://servername/filename.fp5

3. Name the shortcut anything you want.

Now when you click on the icon it calls up FileMaker and loads the file. It also seems to come up quicker than the opener file method does.

One reason not to do this would be that you can build error checking and handling into an opener file whereas with this method maybe not.

Anybody using this method? Pros & cons?

[DykstrL]

Actually, spragueg, the method CAN also be used on Windows. The format is:

"file://[iP]/[folder structure]/[filename].fp5"

If you setup the above URL in a field and then use the "Open URL" script step, it will open the server file. The only thing you can't do is pass the password when opening the file.

So if you test for the user's platform, you can run the Applescript for the MACs and the "Open URL" for PCs.

[Gosub]

Hey folks,

I just registered and have been really loving these forums thus far. I'm literally giddy at all the wonderful information I've found!

That being said, I'm a little wary on the use of these 'opener files'. I've heard about them before, and after reading through this thread, I still fail to see how they are more useful than a simple shortcut or alias sitting on the desktop.

Actually, let me say this: If I don't want to do any error checking/correcting or anything beyond simply opening a file sitting on a server, why wouldn't I just use a shortcut/alias to that file? If the host/file is available, it'll open no problem. If it's not, you'll get an error, but the shortcut/alias doesn't then forget where the file is located (as the opener file does w/out error checking), so the next time the host/file is available it'll work.

It's obvious opener files are used by many people, so please help me understand why I should start using them.

Thanks!

-Stever

Version: v6.x

[stanley]

Stever:

The point of the opener file is that it opens a shared/served file correctly, that is, via "Open Hosts" rather than by opening the file directly, which is a surefire route, in a shared/server environment, to file corruption and data loss. Also, it allows the user (especially a newbie or technophobe) to access remotely hosted files without having to do any navigation.

In a single-user environment you may find them redundant...

-Stanley

[Vaughan]

"I still fail to see how [opener files] are more useful than a simple shortcut or alias sitting on the desktop."

Because a simple shortcut or alias cannot reach a hosted FMP file. FMP files should never be shared on a normal file server: as Stanley points out, it is a sure-fire method for file corruption and data loss.

I'll also add that file-shared databases can easily be duplicated by users so suddenly there will be multiple copies around which becomes a nightmare especially when they are set to multi-user.

[Gosub]

Okay, so opener files are necessary for files hosted on an FMP server, running FMP Server software? Or is it just that the DB is hosted on a machine that isn't sharing the directory where the DB is located? I'm trying to understand if this is a FMP Server issue specifically or not.

Now that I think about it, I do recall one instance where the DB was sitting on an NT server and the directory was not shared, so the only way to access the DB was by navigating to it via the "hosts" function. An opener file would have clearly helped in this situation.

Thanks for the feedback!

-Stever

[Vaughan]

"Hosted" files are those that are *open* in either FIleMaker Pro (client) or FileMaker Server and set to multiuser, so many people can use them simultaneously.

If the NT box was running FMP or FMs then it was a FM Host. If it wasn't then it was just a simple file server, and that's the *worst* way to share FMP files.

[Peter Z]

How do create this script?

If I use the scriptmaker, it offers "Open" but then wants me to choose a path/filename which is not accessible since we need to "Open Remote" to connect to the databases controlled by the server.

Version: Server v5

Platform: Windows XP

[stanley]

Peter:

Welcome to the Forums.

In Scriptmaker, choosing "Open" gives you the normal open dialog; you can select "Hosts" and find the files hosted by FM Server that way.

-Stanley

[Karlos2121]

If I remember correctly, if you hold down the command key and hit period (for macs anyway), that will cancel the script (for stopping the "opening file" before it closes itself).

[Vaughan]

Nope, not if you have "Allow User Abort [off]" in the script.

[Whatsit]

I have a solution which I know works fine in single user. What kind of things (apart from opener files) do I need to think about to make sure that it would work in a multi user environment.

[Vaughan]

Take this question OFF this thread and start another. The answers DO NOT belong here!

Keep this thread for discussions on Opener files please!

[Hurican]

If you want to edit an opener file, the best practice is to Allow User Abort [On], pause the script for more than 1 second (but not too long, because the served file may take a couple of seconds anyway to open).

Hit the escape key repeatedly. That will stop it. (Unless you do have User Abort [Off]. Then you might be able to break the path by simply moving the launcher file to another directory. (I have not tried that though, but I believe it will work.)

Version: Developer v7

Platform: Windows XP

[Vaughan]

That method increases the apparent opening time.

Instead, trap for a modifier key like the Shift key and halt the script.

[Vaughan]

I just posted FMP 7 Opener file in the FIleMaker Pro Sample Files forum.

[thebloke]

I have used the following with success.

if [ Status(CurrentModifierKeys) < 3]

This allows use of the ctrl shift or option keys to stop the script .

As an added feature, I password protect the opener with the same passwords as the ones on the server and when the user opens the file they are prompted for the password.

The script is set to run on opening the file.

Presto the user gets all the files opened and with the correct permissions via the password.