Posted with permission of author -
Darren Terry Wed, 7 Jan 2009 FMPexperts Digest, Vol 11, Issue 18
Yes. Here are my thoughts on conversion from .fp5 to .fp7 format, and file consolidation.
In this discussion, I'll use some specific nomenclature that is important to understand. "Master File" is the file you're consolidating tables into. "Target File" is the file whose table you are moving into the Master File. "Target Table" is the table you moved from the Target File into the Master File. Here are the steps. First, the conversion itself:
1) Before you do anything, make a backup of the solution to be converted. That seems obvious, but I can't stress how important it is. I recommend converting clones with no data -- it's much faster to convert a clone and import the data in, than to convert with data (and have FMP convert the indexes).
2) Then, before converting anything, go through each .fp5 file and make sure the passwords match in each. The .fp7 file format uses case-sensitive passwords, whereas the .fp5 format did not. I've been bitten by this more than once.
3) Then, run the .fp5 files through MetadataMagic from New Millennium Communications. In particular, run the File Reference Fixer to consolidate all file references down prior to conversion. Also run the Conversion Issues report, and go through the issues one by one and fix as many of them pre-conversion as you can.
4) Then drop-convert the files (that is, drop their icons onto the FMP 9 or 10 app icon). Regardless of whether you're planning to consolidate the files down to 1, or leave them as is, or somewhere in between, the first 4 steps of any good conversion project (IMO) are the same as above.
You can deploy the converted multi-file system without consolidating, and consolidate it later. Consolidating files together can be surprisingly easy if you do the steps in the proper order. In a live solution, the biggest problem is kicking everyone out of the solution so that they're not modifying data while you're trying to consolidate.
Here's the order that I'd do it in (assuming you've already converted the solution and it's been in place for awhile as separate files, and that you want to consolidate it down to one file).
1) First, pick the Master File. This is the file into which the rest of the solution will be consolidated. There is no need to think you're going to do it all in one fell swoop. You can do it piecemeal one file at a time.
2) Once you've picked the master file, decide which other file you want to consolidate into it (the "target file" ). Go to the Master File and import from the target file. In the Import Mapping dialog, for the destination, choose "New Table". FileMaker will import the records and define the fields (in a new table) for you.
3) Once that's done, go to Manage Database, to the graph. Find every table occurrence that is currently aimed at the target file's table -- the target table (these will all have italicized names because they are aimed at the target file). For each one in turn, double-click the TO. IMPORTANT: before going further, copy the TO's name from the field at the bottom of the Specify Table dialog. Notice that the popup menu at the top of the dialog says the target file's name. Click there and choose "Current File", then highlight the newly-imported table. Notice when you do that FM has "helpfully" renamed the TO to the target table's name. Just highlight the TO name and paste the original name back in. Repeat this for every TO that used to be aimed at the target file.
3a) You should pick one of those target TOs to be the "main" TO for that newly-imported table of data -- the one that most of that table's layouts will be based on. Usually in any given solution, there's one particular relationship that is the main or primary relationship between the Master File and the Target File -- it's usually the one related by a single primary key. I would pick that TO to be the main TO for the target table.
4) In the Master File, define a new blank layout for each layout in the target file. Name them the same as the layouts in the target file. Pick the main TO to base the layouts on. Make sure they're blank layouts, and leave them blank for now.
5) Now go to the target file and open Manage Scripts. Rename each script in there with a prefix that identifies the script as coming from the target file. For instance, if you're consolidating the Invoices file into the Companies file, rename each script from Invoices with a prefix that identifies it as coming from invoices ("INV" or something). Once you're done, go to the Master File and import the scripts from the target file into the master file. [The reason you prefix the scripts in a way to identify where it came from, is that it's very common to have identically-named scripts in different files of the same solution. For instance, there could easily be a script called "Import" in each file in your solution. You want to differentiate between them post-consolidation.]
6) Now, go to the target file and copy each layout one by one, and paste its contents into the corresponding blank layout in the master file. Make sure the parts are all the same size, and that the layout objects are all in the same place. It's not very hard to do, really. I tend to rely heavily on the Object Info palette for this sort of thing, and nudge things around one pixel at a time with the arrow keys on the keyboard.
The reason you want to define the layouts first, then import the scripts second, then copy the layout objects third is this: When you import the scripts, there will be references to layouts in them (like Go To Layout and Go To Related Record). In order to keep those script steps from breaking, the layouts have to exist in the file already by the time the scripts are imported. But the layouts will contain objects that reference the scripts by name (such as buttons). In order for the buttons not to break, the scripts have to exist in the file already by the time the buttons are pasted into the layouts. Make sense?
Doing it this way will minimize (but not necessarily eliminate) any broken references that might happen during consolidation. Always go through everything and make sure nothing is broken. For instance, Go To Related Record script steps should reference the proper TO on the master file's graph, and the proper layout. Then, let your users start using the system. If all goes well, they shouldn't notice much difference.
Well, if you do it out of order, you'll make your life more difficult than it needs to be. There are a pros and cons to consolidation.
The list of pros includes (but this isn't an exhaustive list):
- Unified security model (define accounts and privileges in one place)
- All scripts in one place
- You are leveraging FM's strengths. It's really designed for a consolidated data model.
The cons include:
- Single point of failure for your system. If the file gets corrupted, the WHOLE SOLUTION gets corrupted.
- You can only ever back up the entire system, instead of backing up only pieces of it.
- It complicates your life to have all tables in one file, if you ever need to update the system with an off-line copy. If you make a v2 of the system offline and it has 30 tables in it, you have to import all 30 tables of data into the offline copy when you put it in place. Ugh.
FileMake.com Links ===========
Converting FileMaker Databases from Previous Versions
Upgrading to FileMaker 8: Migration Foundations and Methodologies
Upgrading to FileMaker 7: How to Employ the New, Advanced Security System
oh my . well first, thanks. this is FAR more complex than i anticipated. For starters, you begin describing the migration with Filemaker 5+ files. As stated, I am in Filemaker 4.1.
i suspect this implies that I need to somehow upgrade from 4.1 to 5. something to proceed.
I'll leave my question at that for now.
No need to upgrade from 4.1 to 5.x/6.
The short guide to conversion:
* Open all files in new version and convert them all in one batch
* Clean up the file references (see help)
* Test the new version and ask here for help with any problems.
Thanks for your input... Another question arises. Is there a stable, earlier version of FM, say, prior to FM 9 or FM10... that I could safely rely upon as a replacement for my 4.1 version - since the only real problem with 4.1 is that it won't run in OSX. I am not an intensive FM user - just simple database maintenance and 4.1 gives me just about all I really need - except for the fact that it is incompatibie with OSX.
ANother way of asking it i guess is.. what is the first, stable/compatible version of Filemaker that is safely compatible with OSX 10.4+ - I guess if i can save a buck or two on an older version that runs fine in OSX, why not?? Thanks for advice!
That would be FM6. That runs on MacOS 10.5 here. However, you would still have to convert your files from fp3 to fp5 format and FM6 is not supported by FMI anymore. It would still mean that you'll have to upgrade .... you might as well upgrade to FM10 then :)