Scheduling regular exports from Server 7?

[Doktor Joy]

Until recently we have used Filemaker clients to peer-to-peer share a database over our network. The client doing the sharing also used oAzium events to regularly run an export script. So, we have a regularly updated text file export on the 'server'. cron is used to call various perl scripts that move this data on.

Due to a change in requirements, we now really need to use Server 7 to share the databases. So, how do we go about setting up automated export from this server now? Server 7 itself has no facility to regularly export data from the files it shares.

Can we do this?

1/ Launch a client automatically via applescript, connect to the remote DB (can Applescript automate this?), login (can Applescript do that?), run an export script, then launch the appropriate perl scripts

What we need is a completely automatic system that will run unattended, with the screen locked (preferably with nobody logged in also!)

Does anybody have any suggestions or have any of you succeeded at implementing something like this?

[Fenton]

It seems to me that it might be simpler than you think. Because logging into the remote files is exactly what FileMaker "opener" files do. On a client machine you could set up a FileMaker opener file with the correct account and password to log in to the remote files,* then do a Perform Script [External, "Export File"], calling the export script in the appropriate file (which the opener file would have a File Reference defined to).

*This would normally be a major security risk, but if you have the machine's screen locked up and the machine physically isolated, and the opener well hidden, it seems OK (I'm not a security expert, so take that with a grain of salt).

You could then use cron (I use Cronnix, 'cause I'm a dummy :-) to launch an AppleScript (or run a shell script), which would just launch the Opener file. FileMaker could take over from there, until the export was done.

The exported file would likely end up loose in the FileMaker application folder on the client machine (which is a known location to an internally run Perform AppleScript; (path to me) as text). You could run a Perform AppleScript to move it to the desktop or wherever.

There is also some talk about Server 7 running plug-ins. I don't know if something might be possible there.

[Doktor Joy]

Fenton, thank you for this response. It all makes sense, but I'm hoping you can explain one thing - which is an 'opener file'.

This is not a term I have come across (am I showing my Filemaker amateurishness or what? ;-).

I'm guessing this is a very simple FM 7 file, with a reference defined to a remote file on the server machine. It uses a script (run on startup) to open the remote file. How do I get this opener file to use the right username and password? (The Open File script step doesn't seem to allow these to be defined).

Forgive me if I'm asking questions I should already know the answer to...

[Fenton]

It sounded like you knew quite a bit, so I assumed you had a passing knowledge of opener files. In fact you described one pretty well just from a hint. The Account and Password can be preset in the File, File Options, Login using Account Name and Password. Usually one would not do this, as it's a security risk.* You'd normally just set it to open with the Guest account, and let the login happen on the remote file.

In the same place you choose the script to run when opening. Usually an opener just opens a remote menu type file, but in your case you could have a local script just call the external export script in the remote file. Calling an external script can be done directly without explicitly "opening" the external file.

Once the Opener runs the script, I have mine close itself, no matter what happens, so it's not hanging around open on the client computer. So, you use ErrorCapture [On] just before the external call, then close. You could show a message if you want.

The trick then is to open the opener to work on it. You can set up a clause in the script so that it will not run the external script or close if certain modifier keys are down.

You can also create a separate "key" file, whose only function is to open the opener without triggering the script. It's tricky in 7 because scripts to run on open happen as soon as a window appears. So, if you open the file hidden, then switch to it in the Window menu, the script runs. You can call a script in Opener, with the step Halt. Then you can switch to it.

* I recently saw an idea in FileMaker Advisor magazine, in an article by Stephen H. Blackwell (Old Advance Man) about "Counterintuitive Security Programming" (a great name for the concept). One of the sections described exporting (which is a rather dangerous privilege, security-wise to have to turn on in the Accounts & Privileges).

His simple but clever idea was to leave it turned off, but create a script to do the export, checking the "Run script with full access privileges." GUI access to such a script would need to be controlled (or hidden) to protect it. But it would be ideal for what you want to do. The Opener file could open with very low level access privileges, and still be able to run your export script.

[Doktor Joy]

Okay, this all makes sense now. I will give it a shot today and see how I go.

Much appreciated.