I'm not sure that will work if the database is open on one of the client machines....
You can certainly set up a script that starts up a timer and only when it is the host that is opening the file, but you'd need to engineer a method for closing out the clients should they leave the file open and go home.
With FileMaker Server, you can set up a disconnect for idle users, but if you are hosting with FileMaker Pro, that's not an option.
You may want to set up two different timers with a start up script. Set the timer for the clients with quit application a half hour or so after close of busniess. Set up the host to close with Quit application at least 15 minutes later than that...
Get ( MultiuserState ) will return 1 on the host machine and 2 on clients.
Thank you--Couldn't I designate a time to shut down on energy saver for the client machines? wouldn't that automatically close an open fm file on the client machine?
Nice idea, but I don't see how you could implement that.
In previous discussions on the subject of disconnecting clients via a script instead of the On Idle disconnect that can be set in server, we've kicked around the idea that you would use Install OnTimer when the user first accesses either the file or a specific data entry layout. Then various events that only take place if the user is actively using the database also contain an install ontimer step that resets the timer back so it starts counting down all over again. Then the timer only runs down and performs a script if the user hasn't tripped one of those script triggers or otherwise performed a script to reset it. The script can then use quit application or close file to close down the client.
The challenge to this method, however, is in putting all the relevant script triggers and Install OnTimer script steps in place to make sure that the file can't shut down when the user is still using the file. Depending on the design of your database and layouts, this could add a great deal of complexity to your interface design.
Hmmm, a feature request for a new Layout Setup and/or File Options controlled script trigger: OnIdle, with a parameter for specifying the interval might be a useful thing to do...
Before InstallTimer (in fact it's so simple and versatile we still use it anyway) we used to produce a similar effect by having a folder of 'Filemaker Triggers'. Each file contained, typically, one script. That script was set to run on File Open, perform some task in another file (usually running a scipt in a remote file), then close itself down. We then triggered the opening of that file (and hence the running of the script) using the standard Windows Task Scheduler.
It is really easy to set up and everyone understands it.
One of the script steps is 'Close File', and options allow you to close a different file.
So could you not have a 'Filemaker Trigger Close File' file on each client machine (the same file will do, presumably) and set each to have a Windows Scheduled task to run at 30 mins before you want the Host to close? And just use the same technique to close the Host, by absolute time, rather than by interval?
I like to 'save' my instances of InstalTimer as you can only run one at a time.
It's certainly an option but not if you want to close users out only if they are not currently using the file. If you have a standard 9 to 5 work schedule and don't have mutiple shifts or salary type managers that come in all hours and access your database, a straight forward use of Taskmanager works--but there's a lot of situations out there where forcibly closing the files at a set time will set up a major lynch mob looking for the developer who shut them out of the database right in the middle of a time and mission critical use of the DB...
One trick for preserving your timers is to open a different window and install a second timer in it. It's not a perfect solution as you then run into issues with windows management and can get some really weird window flashes when the timer in the hidden window is updated, but it can work in some situations.
I really don't know if there is a truly good option here that's going to be a "best approach" for all situations. Everything I've considered has had some realy trade off's to consider.
That is probably over thinking things quite a bit here though. If you have that kind of situation, you really ought to be using FileMaker Server--even if you have less than 10 users--whereupon you can make back up copies via schedule without shutting down the database file.
Oh yes, and it's possible to script a Save a copy as step in a script that only runs on the host computer to make a back up copy without closing the database at all. Then your back up software backs up the file produced by this script (or all files in a designated folder and doesn't try to directly back up the file that is open on the host machine.
In this situation the host is designated an auto-shut-down time, so the tumbrils will be coming for Elaine anyway...
Thankss Sorbsbuster, we're on macs but can I use the equivalent iCal event to run an applescript to run a script in my fm file to close at a certain time of the day? In this case it's safe to say no one will be using the files between 11 pm and 7:30 am. I'll give it a go, seems easier to implement for client machines than messing with any install on timer scripts
Probably not relevent here but timer scripts have a habit of propagating with each new window, rather duplicate window since there is nothing new about it. When I first played with it i had the alarm beep. Eventually my computer sounded like the local frog pond...
You could have the clients excecute a certain script each time the user performs an action that would reset a timer allowing say 10 minutes to auto-shutdown for that computer and to actually shutdown at xx pm.
As mentioned above this will need some careful thought but I think you can open one timer window and send messages to it causing it to reset the timer. Something like
bring window timer to front and perform the timer reset script
Just don't use this window for anything else...
Feel free to use Applescript if you're familiar with that. The Filemaker Trigger File was just something that we all know about and understand, so that's why we use it.
Thanks all for your helpful suggestions! I've gotten the auto close to work with timed scripts through iCal on the Mac, for clients and hosts. I guess I need to put the scripts on each log in account on a client machine, right?
Also, forgive my ignorance, but is there a problem with backing up files that are open but not being used?
A copy made of an open file will have a "not properly closed flag" set that will trigger a consistency check when you open the file. For large files, this can prevent your file from opening for a significant period of time. Since FileMaker saves periodically to the hard drive there is always a small chance that copying the file (should it happen in "mid write", might damage the file.
" I guess I need to put the scripts on each log in account on a client machine, right?" - you would put the trigger file (the one with only the one script in it that tells it the other file to shut) accessible to each workstation's iCal trigger. So that can be local to the MAc or on a server. But yes, for simplicity in one way, stick it on each workstation.
(I said 'in one way' because when you decide to issue the Souped-Up Version II of the trigger file you have to replace them all.)
An interesting point, Phil, about the copy.
I just made a copy of a 128 Meg file I just opened and the copy opened without hesitation. Maybe one needs to do a lot of modification first. How large a file is needed with how many changes to produce the opening verifcation? Is it possible that 12 has resolved these issues?
To avoid the problems you mentioned the following might be tried:
Commit record in every window or close all windows but one and commit record
Flush cache which I believe saves everything in memory to disk
Save a copy
Which means of course that I now have to update my backup script in all of my files. I use this during development since I am using a laptop and run the files locally. When I close the file the backup script saves a copy to several locations including the DropBox folder and I can also perform it manually.