scripted import and export

[kraftyman]

I have a runtime solution using 16 related files. When I update some of the data files, I want the user to update the data by themselves after downloading the required files from my site. I'm having some problems getting the scripted update to work properly. Here is the sequence of steps

1. User backs up data to one ( different folder) and exports all useful data fields into another database, into another folder.

2. User downloads a new version of the file, overwriting the old version.

3. User opens the new version of the file, and activates a script which imports all the records from the exported data. The existing records are updated, and new ones imported. ( there is a unique ID a'la CaptKurt's schema but more characters)

So far so good. In fact the user activates one scipt from the main file which runs subscripts for both importing and exporting from all the subsidiary files. At one stage I forgot to include the "show all records" script step -doh!

What seems to be happening is that filemaker loses the field order during these automated imports, and I get things like dates of birth put into the surname field etc etc.

I don't know why this is happening. It seems like all is well when the databases are compiled and sent out, but somehow it falls over later on. I have some theories, and maybe one of the gurus has the answer.

Theory 1

Filemaker is stuffed....

Theory 2

Filemaker is OK , the developer is stuffed ....

Therory 3

Since I cannot separate interface layers from data layers !@#$%^!,

I end up having to work with all the files which get sent out to the users. Since there about 150-180 fields in the main file ( No @#$%^& variables ) I have to sort the fields in the field order quite a few times during the process. Maybe this upsets the applecart somewhere, and Filemaker runs the import/export script steps with the "current" sort, rather than the one I originally intended. NB: I have "restore" checked in the scripts.

Theory 4

Maybe Filemaker has some internal preference for field order when running imports export. I noticed that no matter what field order is active at the time, the import and export commands pop up the box with the fields arranged in alphabetical order. (Too bad if you want to rearrange 180 fields differently - have a cup of tea!). This might have undesirable effects. For example, if the file is exported with a field order "by type", this might not be interpreted correctly by an automatic import script, if it wants to be in alphabetical order. Do you know what I mean? In theory, when the import script is created and restore is checked, then, however the field order is defined at this time should be remembered.

Currently, I'm going to try to standardise the field order to alphabetical, when I'm packaging the files for the runtime. My bet is that there is a subtle oversight in the design of import/export functions which is the cause of the problem.

Any ideas anyone?

[danjacoby]

It's EXTREMELY dangerous to overwrite files -- better to bring in the new version, then import the data, then (and only then) manually delete the old version.

One solution:

1. Create a "PrepareForUpgrade" script that performs a "ShowAll" in each file so that records are ready to be exported.

2. Create an "Import" script that imports records using the "Matching Fields" import order (as opposed to "Last Import" or some other import order) -- you might have to have the user select the file to import from; test it, 'cause I haven't. Oh yeah -- probably a good idea to check the "perform without dialog" box in the import script step.

[kraftyman]

Re: It's EXTREMELY dangerous to overwrite files -- better to bring in the new version, then import the data, then (and only then) manually delete the old version.

I agree but this suggestion would not work with a runtime because the files are bound. Naming files becomes a nightmare. The original file might be called version1.usr and the new one version2.usr. If I get version 3 out, then the version 2 file won't "know" about version3. usr, so the scripts will no longer work, and the user will have to pick the files. There is still the fact that any user interface changes in the new file require the user to delete the old file and use the new.

I tried doing this with 3 files with the same name in "current", "old" and "new" folders, but this was already pretty tough. It was difficult to keep up with which script was external, if all files were essentially identical. Now I have and need 16 files. It would be a logistical nightmare to switch between new and old versions like this. Filemaker gives me no control over file names, I would have to use batch file to rename them to stop the user having to do any thinking. Aargh....

No good...

Re: Create a "PrepareForUpgrade" script that performs a "ShowAll" in each file so that records are ready to be exported.

I have already done this

Re:Create an "Import" script that imports records using the "Matching Fields" import order (as opposed to "Last Import" or some other import order) -- you might have to have the user select the file to import from; test it, 'cause I haven't. Oh yeah -- probably a good idea to check the "perform without dialog" box in the import script step.

I have already done all of the above too. You will find that if you actually unselect "perfom without dialog" to see what FMP is doing, you will see that something odd happens. The field order is no longer "matching fields", but "previous order". This is my real question. Which previous order? The order entered when "matching fields" was chosen? Or is it the order of the database fields when the script was saved? Or is it the field oder that the database is in since i changed it to "by type" or " by creation order"

I don't know.

I would really love to be able to disassociate interface from data. Filemaker is limited in the things it can do with related fields, which cause all this trouble in the first place.

[danjacoby]

Re: I agree but this suggestion would not work with a runtime because the files are bound. Naming files becomes a nightmare.

How about renaming the enclosing folder for the bound upgrade?

[kraftyman]

Intersting idea, I haven't tried this. I actually do use separte folders for the exported/backed up data anyway. This ensures files do not get overwritten, and the data is always retrievable.

The user would launch the new file and import from the old. I must try this from the runtime. There could be a problem since the file names would have to be identical to make sure that all the scripts worked, and the application could get incredibly confused, not to mention the developer... I will let you know how this goes

[DykstrL]

1. A scripted Import in FMP 5.0 will remember "Last Order". In FMP 5.5, it will remember "Matching Names".

2. If you use the same extension, binding key, version and solution name, any and all files bound - regardless of when or where they were bound - will be considered part of the same solution and will run with the 'EXE'cutable. This holds true for both Mac and Win solutions.

So.... assuming that #2 is true for your runtime, and you don't have an awful lot of files (one of my solutions has about 476 files), you could either automate (with a CMD file for Win and Applescript file for Mac to rename the old files (file1old.usr), or have the user rename them, then set your script to import from the 'old' named files. The CMD and Applscript files could be started using 'Send DDE Execute'.