Version Update Suggestions

[cpbatwes]

I'd love to start a thread to gather everyone's advice on the best system for implementing version updates of Filemaker solutions. There are a lot of great minds here, and I'd love to know what the best ideas are. I'm particularly concerned with implementing a version update in these conditions:

a) Users are using the system all day - I have to develop in clones and then import the data into them

There is always a concern that the data may have become corrupt - if I automate the export/import, how do i be sure I capture all the records. I've automated this for the past 1 1/2 years, but occasionally I lose records on the import! Very frustrating...makes me not trust the automation (exporting to MERGE and using "matching fields" on the automatic import script)

Any advice would be really helpful!

Thanks

[BobWeaver]

Everything should import, but remember that you will only import or export whatever is in the current found set. You could probably put some kind of safety check in the update script to count the records in all the files to make sure that the numbers agree. But basically you need to do a show all records in the old file before you import the records from it, or if you are exporting from the old file to an intermediate file, do a show all records before exporting.

And, of course, most importantly, if you are using auto-enter serial numbers, make sure that you reset their next value to the current maximum plus one.

[cpbatwes]

Thanks Bob. Each file I use has a script that shows all records before exporting the data to a MERGE file. Any other ideas?

[Vaughan]

Watch out for any auto-generated serial numbers. The auto-enter options will need to be reset to take the new records into account.

[BobWeaver]

When I used to do updates at a client's site, I would kick everyone out of the system, shut down FM server, and then fire up a regular copy of Filemaker on the server machine to do the updates. Once in a while another user would start accessing the files while I was doing this. Now, I always make sure that the server computer is not accessible on the network when I'm doing upgrades, either by unplugging the network cable, or else changing the server IP address to a false IP address that's not on the office subnet.

[falkaholic]

I've made auto updating into my templates before starting a big project..

For example, I have a 20+ file system, where each file has a update script. The script does the import and sets the serial number to the right value (and even finds and adds the 3-letter prefix i use). All the scripts prompt for a file to import before erasesing all the records before it does so.

As for the actul update, I usually copy the files from the server to my workstation (via AppleTalk), if the databases are needed I leave them up, otherwise i take them down. That way the users can still use the databases and won't connect to my computer. As well, its helps it you make a mistake because you don't have to restore from backup.

Other point, always plan ahead and put in the extra effort in when you can, that way you might not even have to do an update. I've found this out the hard way.

[BobWeaver]

I usually copy the files from the server to my workstation (via AppleTalk), if the databases are needed I leave them up, otherwise i take them down. That way the users can still use the databases

But what if the users are adding records while you are updating? Won't their new records get skipped in your update?

[Eric Crisp]

Well, I just got done writing an auto-update routine a while ago and I'll list what I did this time (Each time is a little different based upon the systems).

1. I always put in a routine for that will turn off/on/hidden filesharing for every file. The first step once you have the files down from the server is to run this so that nobody can access the files during the import.

2. Write a routine to find all the records in all files.

3. I wrote a routine that goes through all the files after all the records have been found and stores the number of records in a repeating field. 1 repeat for each file.

4. Export all the files to a new file named Temp_<Filename>.fp5. The export mapping needs to be reset if you add data fields and I wrote a simple flagging routine to keep track of this.

5. Open up new set of databases and run routine that imports all the data from the Temp_ files.

6. Run routine to gather the ending record counts and compare to beginning record counts for any errors. I wrote some simple calcs that display a message if the counts differ as a double-check.

7. Reset Serial numbers.

I think that's it from what I remember. I've written some other update routines where you can specify specific files to be update or not (only really matters if you have lots of records and want to save time) and/or tracked the developer versions (multiple-developers on the project) but those probably aren't what most people have to worry about.

Hope this helps!

Eric

[cpbatwes]

Eric, you mention above:

4. Export all the files to a new file named Temp_<Filename>.fp5. The export mapping needs to be reset if you add data fields and I wrote a simple flagging routine to keep track of this.

Could you please explain why the export mapping needs to be reset if you add data fields? I could really use an education on how the heck Filemaker stores export and import mapping anyway, as I've had lots of trouble with export/import scripts - and yes, I constantly add fields to my solutions.

Thanks!

[Anatoli]

RE: 1. I always put in a routine for that will turn off/on/hidden filesharing for every file. The first step once you have the files down from the server is to run this so that nobody can access the files during the import.

That is also good for speed. Single user files are running faster.

Or, you can disable the network protocol so nobody can open the files.

[Nik]

FileMaker is particularly brain-dead when it comes to this. I'm currently working on my own solution to the problem that involves one tiny ScriptMaker script in each file (which is easily imported to new files with minimal modification), and one moderately complex AppleScript. The only thing I'm stuck on is migrating Value Lists to the new version. Anyone got any ideas how to do this (I haven't really looked into it yet)?

The per-file ScriptMaker script is called for every file by the AppleScript, and it simply does the following:

1. Enter Browse Mode

2. Show All Records

3. Delete All Records

4. Import (restore order - Matching Field Names; from specified file)

5. Update the next serial value for field, "ID", to Max(ID) + 1 (this has no effect if there is no field called "ID", or if there is an "ID" field that doesn't use auto-entered serial numbers).

This ScriptMaker script works beautifully so far, and the specified import file is the ONLY thing that needs to be altered for each FMP file that includes this script. I specify a file that is in the current file's enclosing folder's parent that has the same name as the original with " copy" appended to it (such filenames are automatically used by the Finder when duplicating, which is very handy when it comes to the AppleScript).

I'm only part way through writing the AppleScript, but I've AppleScripted FileMaker a lot before, and I don't think it'll be a problem to get this working. Here's what the AppleScript will do:

1. Get a folder containing the old version of the FileMaker files (either by dragging it onto the script, or by an Open dialogue), and from that create a list of all the "FileMaker Document" type files in it. Create another list of "FileMaker Document" type files in the same directory as the script itself (these are the updated versions). Make a list of the files that are in both lists. So now we have 3 lists: all the old files, all the new files, and the files that need updating.

2. Quit FileMaker Pro (others may like to stop sharing instead - whatever rings your bell; I've already got an AppleScript that will start/stop sharing of a set of FileMaker files so that could easily be incorporated).

3. Duplicate all the old files so that the duplicates have " copy" appended to their names.

4. Move all the original old files to a new directory called "Old Files".

5. Copy all the new files to the directory called "New Files" at the same level as the "Old Files" directory (so now the original directory contains all the copies of the originals, the "Old Files" directory and the "New Files" directory).

6. Launch each of the FileMaker files in the "New Files" directory that has a corresponding file in the "Old Files" directory, and run it's update script as a privileged user (I've already written an AppleScript that will prompt for a password and log into each of a list of FMP files using that password).

7. Quit FileMaker Pro

8. Delete all the " copy" files.

8. On success, move all the files from the "New Files" folder up one level (and delete the empty folder). On failure, move all the files from the "Old Files" folder up one level (and delete the empty folder; leave the "New Files" folder there for invetigative purposes).

Another thing I'm considering incorporating (since me and my clients are all on Mac OS X) is to wrap the AppleScript and all the new FMP files into a "package" (ie, a directory with ".app" appended to it's name) and set it up so that the entire thing appears as a single stand-alone updater application.

I'll let you know how I get on when it's finished. If anyone's interested in seeing it in action, when I'm done, let me know.

[JerrySalem]

One other thing to remember (besides serial numbers)

Value Lists. These little buggers don't import. THis is especially hairy when you have custom value lists that the users can modify.

Anyone have any suggestions on dealing with these guys, besides not using them , since that isn't a good option for me.

Jerry

[LaRetta]

Hi Jerry,

No, you can't 'import' a VL but you can access them easily nonetheless. Easiest way:

You need a relationship. If one doesn't exist, use constant key 1 to establish it. Then, from within your main db (in which you want to capture a VL), create a new VL.

If you want to capture a Custom VL, point to the dB with the VL you want. Select 'use value list from another file'. You can also use 'use values from field', point to your other file and indicate 'only related values' - options abound!

Now, if you want to import a VL from a different fp5 (someone else's program not associated with your existing files, for instance) you could consider a Control db which can be used by any other dB, based upon joining on constant key 1.

From within the db which contains the VL, create a calculation (text, unstored) with:

ValueListItems( Status(CurrentFileName), "YourVLName")

If you have several VL's, create a calculation for each. There may be an easier way than calcs (like writing to text multiline), but this will give you the idea.

Perform a find that isolates only ONE record