Open Database on Launch

[schomer]

Is there a way to have FileMaker 7 open a specific served database each time the application launches? I am so tired of having to go to the Recents menu to open the database everytime. Seems like a nit picky thing, but I never open another database. It's always the same exact one. () Thanks for any help. - Schomer

[stanley]

Schomer:

What you're after is called an Opener File. There are tons of threads on this topic, but the basics are this:

1. Create a FileMaker 7 file on your local machine.

2. Create a script which opens the remote file you are always opening (and then closes the local file.)

3. Set that script to run automatically when the local file is opened.

Now, instead of launching FMP 7, just double-click on the local file (or put the file in your dock and click there) and it will launch FMP and open the remote file.

-Stanley

[Ted S]

Ahhhhh the opener file........ once a clever workaround, nowdays mostly unnecessary.

Since you're on a Mac I don't know if this will work but it does on Windows. Just create a desktop shortcut:

fmp7://10.20.30.40/HostedFileName.fp7

10.20.30.40 is the IP address of the FM Server.

I find myself on a personal crusade to kill the opener file method. It seems like a lot of work when a simple shortcut works just fine.

[stanley]

Ted:

I don't find it to be much work, and also, as it is a FileMaker icon, people know that they're headed toward FileMaker when they click on it.

-Stanley

[Ted S]

The icon can be changed to any of the regular FM icons via the conventional method. I just like simple and easy.

[thomasjojo]

Ted, thats exactley what I came here for today.

Thanks!

I join ure crusade...

[-Queue-]

Opener files are nice, IMO, because you can present a comprehensible message to the user if the system happens to be down (due to scheduled work, application error, etc.)

[Mike D.]

I have one client whose network is a perfect example of what NOT to do - they only have 1 user account (user1) defined for their 6 users. I use opener files that log in the different clients based on where they are located (Sales Office, Production Foreman, etc). The opener files use a "re-login" script in the main file to sign in with the various accounts/privileges. Of course, this client also only has 1 email address for the entire company so he can see all the emails coming and going....

At least he pays my invoices with no problem, so he can't be ALL bad.

Mike

[stanley]

At least he pays my invoices with no problem, so he can't be ALL bad.

In my universe, that makes him a good client. I'll put up with almost anything, so long as they pay for it in a timely fashion.

-Stanley

[Ted S]

Opener files are nice, IMO, because you can present a comprehensible message to the user if the system happens to be down (due to scheduled work, application error, etc.)

Okay, I guess there remains at least one rather minor reason to use opener files.

[LaRetta]

In addition to providing a message if the host can't be accessed, an Opener file can protect itself from being changed or trashed. It will simply provide a message and then close itself.

If Shortcut is used and the Host is down, User will be provided an option to Browse and respecify what their shortcut points to. Very bad.

I used to get calls at night (24-hour facility) when staff would misdirect their shortcut and then couldn't get into their file. I've never had a call about an Opener file. They are sweet.

[Ted S]

I would think that if the staff had the "skill level" necessary to misdirect their shortcut, they would also have the skills to delete their shortcut to the opener file or maybe even delete the opener file itself. I would expect this action would provoke a midnight call.

I still not sold.

[-Queue-]

What if you made it read-only?

[stanley]

Opener files should always be read-only, and the user should not have the admin privileges to move it or delete them. If there's a shortcut to the opener file on the desktop (or in the dock in OSX) there's not a lot you can do to stop the user from deleting that, but then again, it's impossible to stop all users from being idiots some of the time.

Opener files have the edge over desktop shortcuts for a number of reasons - customizable error capture (keeping the user as far away from the OS as possible), customizable startups depending on which machine you're coming from, and being able to dump the thing onto a CD and give it to the office manager or head secretary with a post-it note on it saying "if they can't start FileMaker, install this file on the desktop and tell them to double-click on it."

-Stanley

[Ted S]

Sorry, still too much complexity for such a simple task. I will however concede that there could be circumstances where an opener file would be the better choice, but for most folks, I think a simple shortcut is best.

Oh yeah, TASTES GREAT!

[-Queue-]

Another advantage I failed to omit previously is the default password option. Conceivably, you could create multiple opener files, each with their own default password, and set up a domain login script to copy the appropriate file to the user's system, thereby eliminating the need to enter a system password. This may be a more useful idea in version 6 or prior though.

I am not arguing for or against the usage of openers, but they have worked well for me over the last 5 years and have not required much effort besides their inital setting up.

[Ted S]

Okay, I can see that. For me entering the password is a non-issue because we are using Windows authentication so users never have to enter any password. This is a HUGE improvement in v7.

[Andreas T.]

Hi.

Is there any way to make an opener file that will be able to open served files using external authentication accounts?

I can only make it work with the built in Filemaker accounts.

I suppose it's because the opener file is not located on the server, (logically enough), but I am looking for a way around this.

[Andreas T.]

I found out this one myself, it's really very easy.

Just create an empty database with a startup script.

In the startup script open the actual opener file which must reside on the server and include the same external accounts you wish to use in the other databases.

That's it.

[KyleK]

Ahhhhh the opener file........ once a clever workaround, nowdays mostly unnecessary.

Since you're on a Mac I don't know if this will work but it does on Windows. Just create a desktop shortcut:

fmp7://10.20.30.40/HostedFileName.fp7

10.20.30.40 is the IP address of the FM Server.

I find myself on a personal crusade to kill the opener file method. It seems like a lot of work when a simple shortcut works just fine.

Ted,

I was led to this post because what you have described is exactly what I want to do. Has Filemaker Pro 8.5 using Filemaker Pro Server changed the ability to do this. When I try to edit a short cut the string "fmnet://192.168.1.94/filename.fp7" isn't recognized.

I guess my question is... how is "fmnet:" defined?

Kyle

[JerrySalem]

Is there a way to do the same thing on the Mac Platform?

(that is use the 'explorer shortcut' method, not an opener file)

Jerry

Edited April 18, 2007 by Guest