1 of 1 people found this helpful
Unless your "filename" field contains a file path as well as a file name, you would be relying on FIleMaker to open the file from a default path (which would vary depending on whether the current file is hosted).
Also, you've given us the details of your set variable step, but you haven't said how you're then trying to use the variable to open the file. The Open File[ ] script step doesn't accept variables, but requires you to select an existing External Data Source or add a new one, and then it uses that.
Notwithstanding that, if the file is stored locally, one option you could consider would be to open the file by calling its path as a URL using the Open URL[ ] script command - or, if the user files are hosted, you could calculate an fmp7 along similar lines URL to open the appropriate file. Alternatively, depending on the platform, you could use a calculated AppleScript or a VBScript to open a local file file from its path.
Another (slightly circuitous) option to open local files would be to insert the appropriate file into a global container field (supplying a variable to specify the path and file name) and then use the Export Field Contents[ ] command (to place the file back into its original location) with the "Automatically open file" option enabled - thus causing the file to open.
Having said all that and given you some options to consider, I have to say that there might be some better ways to accomplish the clients requirements - such as having the users all open the same file, but see their own records or their own "space" within that file - eg using privileges and/or RLA to control what each user sees.
Sometimes the fact that something *can* be done a certain way (eg a separate file for each user) doesn't necessarily mean that it *should* .
R J Cologon, Ph.D.
FileMaker Certified Developer
Author, FileMaker Pro 10 Bible
NightWing Enterprises, Melbourne, Australia
I agree wholeheartedly with your recommendation that a file for each employee is overkill and that record isolation within a single file would be normally be more efficient. This file set is a solution written by a self taught, full time IT person who left the organization quite suddenly. There are over 30 employee files in use, many of them in use for a number of years. To change this method at this late stage would open a can of worms that doesn’t need opening. I had hope to script Open File using a dynamic file path and file name to generate the external file reference, but as outlined in my first post it is a bahaviour that works only one way...that is to save a file, not open a file.
I decided that a calculated external data reference would make all scripting much more efficient whilst enabling dynamic interaction with the selected employee button displayed on the interface file. This file previously had a button per employee defined to run an individual script with individual external file references. The interface is now a portal displaying the buttonName field. Selecting the button sets a variable “$file” with the calculated external file reference below:
Let ( [ numChar = Length ( Get ( FilePath ) )- Length ( Get ( buttonName ) ) ;
path = Substitute ( Get ( FilePath ) ; "fmnet:"; "fmp7:/" ) ] ;
Left ( path ; numChar ) ) & buttonName & " time logs.fp7"
EG: fmp7://10.0.1.3/george time logs.fp7
thus producing a dynamic URL based on the host, the content of the buttonName field and the balance of the file name. This calculation is a field in the Staff file because it will be called on by a myriad of scripts.
Generating the buttons is a simple relationship of 1::1 between the interface file and the staff list. The interface is a constant 1. The staff key value is also 1 and is based on any staff members who are active, ie value list of 1 formatted to display as a check box.
The “Active” checkbox enables the users to define which employees should display in menus and the buttons described above.
It’s a simple solution yet slick in it’s execution—the users love it!
Thanks for your input Ray