Importing from user-selected folder

[Mandu]

I want to be able to send my client clones of his databases whenever I make miscellaneous tweaks to the non-data portion of a database (scripts, field defs, etc). He should open the clone and run the script "Upgrade" which asks him to locate the folder containing his current db files, and then runs Import for each file. The files in the current and new folders have matching names, if it matters.

I figure this is a FM script that kicks off an Applescript to prompt for the location of the source data. But how do I then run the Import script step, telling it where to import from? I'd rather him not have to be faced with the Import dialog for each of the four files.

- - -

And, since this is intended to simply update to the non-data portion of his database (is there a word for that?), perhaps there is an entirely different approach that doesn't involve importing?

Thanks,

Chap

[Wim Decorte]

Well, if there is no data to import in the first place then your client could just replace the old files with the new ones, right?

[Mandu]

There is plenty of data to import. He's been using the old files for weeks, and now I've made some tweaks to reports, scripts, field defs, value lists, and such. I'm proposing sending him a clone of the new DB and giving him an easy tool to copy his old data over.

[Fenton]

In version 6 you cannot separate data and interface. So you'll have to import. It can, however, all be scripted. Personally I think I'd let him put the new databases in the correct location, then run the scripts. You could use AppleScript to verify that everything was in the right place before starting the process.

Basically FileMaker only Imports from a fixed file name and location. So it's easier to put them side-by-side to start with. You can set up the whole routine on your own computer. You have to do the import once to set it.

One trick is to temporarily rename the new file; but only 1 at a time. And go to a layout with NO related fields on it, so other files aren't opened in the background. Put it in the same folder as the regular files for now. As long as the other files are present, it will be OK. While you're setting it all up, the folder looks like this:

Files folder:

fileone.fp5

filetwo.fp5

fileoneNEW.fp5

filetwoNEW.fp5

You can open "fileoneNEW.fp5" to a blank layout, and it will be happy. Filetwo.fp5 will NOT open. And it would be OK if it did, as long as no related fields back to fieldone.fp5 were visible.

The reason for all this is that now you can safely import from fileone.fp5, in the other folder, without confusing FileMaker or yourself. After setting up the import, rename it back, then do the same for filetwo.fp5.

When you're running the Update, it looks like this:

Files folder:

fileone.fp5

filetwo.fp5

New files folder:

fileoneNEW.fp5

filetwoNEW.fp5

The technique I developed was derived from the core idea of Eric Schied, way back pre-5.5 (when it was really a pain). Post 5.5 is simpler, because of the "Serial" functions/steps. It requires that the original file have a Prepare for Update script, with Show All Records. This could be done manually I suppose. BruceR had another idea once, to use a Constant relationship to show all. In version 7 this would be automatic in a closed file.

Your idea of using AppleScript is actually a good one. The somewhat scary "overwrite the original file" method of Eric's would not be needed if you used AppleScript to "switch" the files. His idea is pure FileMaker, hence cross-platform.

So, the attached solution works, but it's old, it's complex, it's scary; and I've rarely used it. If you manage to strip it down and use AppleScript, please post your findings. Good luck (you may need it -)

Oh, the odd thing is the both the original files and the New files are the same; they have the same scripts, everything. So it's a little difficult to tell that it worked. It could be a hoax :-/

The pw is "fenton" Read the ReadMe's.

MedUpdaterv5.zip

[bruceR]

Actually I have a couple of other methods that I now use commonly.

SEE ATTACHMENT

All files have closing scripts that show all records; they act like Filemaker 7 files do.

All files have startup scripts that look for two conditions, then run a self updater:

Test for "clone" in the current file name; test for zero records.

Go to Layout [blank]

If ( patternCount(status(CurrrentFilename), "clone") and (status(CurrentRecordCount) = 0) )

Perform script [Autoupdate]

Close

Else

#Do normal startup stuff

End If

The go to blank layout step make sure that no related flles are auto-opened.

The autoupdate script tests to see that no other databases are open.

The autoupdate script then imports records from the original file, updates the record ID field, then saves a copy of itself with the original file name, thus overwriting the original file.

MedUpdatervNew.zip

[Mandu]

Boy, that *is* complex! -)

I'm leaning now toward the idea of Exporting from the old files and Importing to the new. Probably just tab-separated values. None of my fields is a container, the globals are all temporary values that don't have to be copied, most calculations are unstored. I'll have to look at the issue of serials.

Apart from the issue of container fields, and the extra disk space needed for the export files, what are the problems with this approach?

[Fenton]

I don't see that Exporting makes it any easier. In fact it adds an unnecessary process; because you still have to Import.

Much of the complexity comes from the tricky business of overwriting the original files with the new files. This is done mostly so that the user doesn't have to deal with moving and renaming files (neither of which is very difficult, but it's critical that it's done correctly).

The 3 essential steps, whether manual or automated:

Show all records in the original file

Import those into the new file

Reset the Serial ID in the new file to the next value of the original file

I think that your original suggestion of using AppleScript may help (but not much). Rather than overwriting the original files with FileMaker (which is a little scary, but works well), you could do it with AppleScript. It could also check that all files were in the right places (though FileMaker can also, more or less, with Error Capture).

Actually it comes to about the same thing. Many developers have worked on this routine over the years. If there was an easy way I think someone would have found it by now. It is one of the reasons why "separation of interface and data" is such a big deal now.

[Mandu]

I don't see that Exporting makes it any easier. In fact it adds an unnecessary process; because you still have to Import.

Much of the complexity comes from the tricky business of overwriting the original files with the new files. This is done mostly so that the user doesn't have to deal with moving and renaming files (neither of which is very difficult, but it's critical that it's done correctly).

I was thinking that, by splitting it into two steps, I might avoid the renaming problem altogether, since the old and new versions of the file would not have to be open at the same time. And since it has to be scripted in some way or another, it could still be a "one-click" operation.

Well, I'll give it a try and see how it works, and let you know.

[Fenton]

Yes, it's true that it's a bit less tricky if you export then import. But it's a similar problem. Now you have 2 folders with indentically named files.

You could tell the person (repeatedly) to manually throw away the old folder; or do it with AppleScript. But you'd have to know the name of that original folder, both to export/import, and to throw it away. That would be true of most methods though (unless you put all the files together in the same folder, which you couldn't do unless they had different names).

[Mandu]

You could tell the person (repeatedly) to manually throw away the old folder; ...

-)

Well, I gotta share a story that happened last night...

My client has V1 of the DB, and she has been editing it, adding new workshops, new participants, etc. Along the way she has requested some operational changes, so I made the changes at my end and sent her clones of the DBs. I gave very detailed instrux for how to import data from her existing DB into the new clones.

She followed the instrux to the letter, and successfully imported her data from V1 to V2.

So I get this voice mail last night saying that the fixes didn't seem to be working. I tried to replicate, but from everything I could see, they *were* working, just fine, thank you.

Finally, after about 45 minutes, I spotted the flaw. It really hadn't occurred to me as a possibility.

After importing the data from V1 to V2, she...

She had continued to work with V1. And not by accident, either.