Use FilePath in import script?

[Pierce R. Butler]

I'm working on a project in collaboration with another person who is likely (and with good reason) to park renamed copies & clones of the configurations I develop all over any of multiple Macs, and to assign work to various assistants.

Several processes we use require importing data from one table into another table within the same file, something I'd hope would be fully scriptable.

Say my file is named Alpha, and data needs to move from the Source table to the Destination table: I still want it to move between those tables even if the file is renamed Omega, without user intervention beyond launching a single script.

After reading several of the threads in this forum, I've gotten as far as creating a global calc field in a given table called gcFilePath and a script step defining a Script Variable as $$PhilePath = table:gcFilePath.

A following script step reads "Import Records ["$$PhilePath"], but all it generates is a message saying that "[FileName]" (which it gets correctly) cannot be found, followed by an Open dialog box in which the correct file is highlighted. A Custom Dialog added just before the Import step displays "$$PhilePath" with a correct value, so the problem seems to be with the Import Records step.

Fwiw, results are the same with either spaces or underscores used in the filename (or with the import File Path List including both filemac:$$PhilePath & file:$$PhilePath).

(Oddly, at least to me, the gcFileName field continued to display "File Name" even after the file was closed, renamed "File_Name", and re-opened. When I moved the file to a subfolder within its previous home folder, the Open box started out at the previous folder, with no file selected, rather than finding the proper location; the gcFilePath field and the $$PhilePath Script Variable continue to display the previous value. I had to duplicate the field to get it to update. Is this going to stick every time?)

This project doesn't need to look slick, but it does need not to add confusion for unknown & untrained users. What's it going to take to handle intrafile transfers smoothly & automatically?

TIA for all comments & suggestions,

Pierce

[Fenton]

I don't know exactly what's happening with your many files. I have never used FileMaker in this way. I do have some Time tracking files, for jobs, which I just keep as standalone files. But I don't import into them.

My solution to your problem would be to run an AppleScript, in a Perform AppleScript step, to rename each file to a fixed filename, the same as the one you originally set up the import with. Then I think FileMaker would know it was the same file and would keep the same import order. Then rename it back to what it was.

It would be easiest if the files were in the same folder as the file you're importing into. It wouldn't have to be. But you'd need to get the location with AppleScript, and store it in a FileMaker field, so a later Perform AppleScript could rename it back again. If they were in the same folder you could use FileMaker's Get ( FilePath ), then translate/calculate the result to get your current folder path:

Substitute ( Get ( FilePath ); [Get ( FileName ) & ".fp7"; ""]; ["file:/"; ""]; ["/"; ":"] )

I would do this in 2 scripts. The 1st chooses the file, renames it, then calls a FileMaker script.

The FileMaker script Imports the file, then runs a Perform AppleScript to rename it back again.

This allows FileMaker to handle the timing. Which it does very well. FileMaker will not run a script step until the previous finishes. So I let it handle situations where timing might matter, such as importing a large file and renaming it (though it might be fine to just do it all in one AppleScript). Therefore FileMaker would need to know the location of the file.

Here's a little renaming example file.

Rename8.zip

Edited October 2, 2006 by Guest

[Pierce R. Butler]

Thanks for your reply, and for the example - very generous and thoughtful of you.

I'm not sure your solution would work in this case, since my collaborator often has good reasons to rename and relocate the files he uses. Because we're working with very large datasets - enough to cause FMP to slow down absurdly - he often carves off a subset of the file and assigns it to a helper, so the changed name is usually significant - and the filepath may include a different volume or machine.

Moreover, this seems like a kludge that shouldn't even be necessary: if a given file can obtain its own name and filepath, and that data can be put into a field and a script variable, then why can't it be used in scripts?

Assuming it _can_ be made workable, I have hopes for employing this technique in other scripts to save some significant time: for example, automating the time-consuming process of splitting up the combined file and deleting the unneeded info from each subfile overnight. This would require a script to name the saved-copy it creates, and perhaps the saved-copy would need to read its own name in order to find the records to preserve from deletion (though that latter step could be done with a text field somewhere).

Again: thanks much for your help & advice.