5.5->7 upgrade of relational db

[alexliz]

I am quite experienced in FMP5.5, but an FMP7 newbie. I realize that multi-file dbs in 5.5 become multi-table dbs in 7.

My question is: is there a quick way to import/convert a relational database system of about 20 files from 5.5 to a v7 file, and somehow to import into each new table of the single file all the field definitions, relationships and scripts? Or do I just import one of the 5.5 files, and then basically sit down for days and re-write all the remaining 5.5 files as additional tables within the newly created v7 db?

Many thanks, people.

[SteveB]

I don't use v7, but I know there is a tool called FM Robot by New Millenium that can assist you.

Steve

[alexliz]

Hi Steve,

I guess FM Robot might help, however I am not in the business as a developer; I'm just responsible for my own office DB in FMP (i.e. I made my own DB), so the FM Robot price ($199 for a commercial beta) is a little steep!

Anyone with a tip inside FMP (or even a shareware/freeware plugin) to help migrate my 20 or so files from v5.5 to v7 without my having to sit down and rewrite the whole database?

Many thanks, as always.

[IdealData]

Do you need to put all your v5.5 files into a single v7 file ?.

You could just run it as it stands.

[Fenton]

You could compromise. See which of the files really belong together, and move only the simple files inside their logical parent. Not knowing your files it's kind of hard to say what these would be. And much of it just depends on how far you want to go with that. But something like a Phones file or an Addresses table (multiple per person) should certainly be tables within the People file. Any line items table could be brought into its parent.

Remember that you're going to have to do some clean-up anyway. File References for a starter. Then there's the Accounts, which you may want to change, in all files. So the fewer files the better for that.*

You will also need to look at scripts that move between the files, and see how the Select Window ["file name"] have been added. I don't much like those, as they are hard-coded. It is better to put a Select Window [ current window ] at the other end, in the called external script, if needed.

The thing about 7 is that it works off of Table Occurrences (what we used to think of as "relationships"; but they are more than that). If you create a table occurrence in a parent file of the new "child" table, and it is named the same as the original child table's (in the child file), and you have layouts named the same, then you will be able to import scripts and most things will match up (hopefully).

*I have an example in the Sample Files section that shows how to script creation and management of Accounts; very useful if you often change these in a multi-file solution. The scripts are fairly modular, based on a single table occurrence in all files, with scripts that can be imported between the files.

[alexliz]

Mark:

You mean, just convert the 20 files into .fp7, keep them in the same hierarchy on the hd, and use them as inter-related single-table files making up one system, pretty much like what I have in v5.5?

What would be the gain in ease of development from migrating to FMP7 if I do that?

Sorry, Fenton, I'll study your post and get back to you. Thanks for the reply.

[alexliz]

Hi Fenton, I think I like the content of your post, esp. your last para. I take it you mean that I set up some basic foundation in the new v7 file and then import from each child file, saving myself typing in all my scripts?

[Fenton]

FileMaker 7 really changes the rules as far as to how you store and use data. It is very flexible. You can keep your data in separate files, or in separate tables in one file. But that's not all. You can also create "table occurrences" of the external files in the Relationship Graph of a file, and use that local table occurrence as if the external file was a local table.

The latter is especially handy in scripts. You no longer need to flip between files to work on a script, even if it works with separate files (one of my pet peeves with 6). If you create layouts in the local file, you can base them on a local table occurrence of the external file, and they behave exactly the same as the external file's layouts. So they can be targetted by the local script(s). (Read below about "table occurrence groups".)

It is not an "either/or" decision. You can mix the old structures with the new. Though you'll find that the new is so much better to work with that you'll gradually move things to it whenever convenient. It is also a little confusing when you have 2 layouts, one in each file, which are basically the same thing.

What this means is that you can move your design to a more modular structure. Decide what the "main" files are, and let them be the center of activity for the module. If there are a few simple "subsidiary" files for a main file, move them inside as tables right away. If one of them is subsidiary, but very complex on its own, it can be left as an external file; but perhaps some of the scripts can moved to the main table (those that begin and end in the main file especially).

There will already be a table occurrence of the subsidiary table in the main file, as related to the main table (much like 6). But you probably should create a brand new one, which is NOT connected to that main table occurrence, and use the new independent one for any layouts for the external file (or a complex separate local table for that matter). That way if you proceed to expand, you will not be trapped into one table occurrence group (TOG; a group of table occurrences which are connected). It is a better structure in the long run.

So, you can create table occurrences in a local file, named the same as the one in the original external file, as well as layouts. The local TO can refer either to a local table, or to an external file; it doesn't care. Layout objects can then be copy/pasted from the external file, and scripts can be imported. Most of it will work; what doesn't will be /*commented out*/, so you can see and fix it.

WARNING: You can convert your existing files. You can even use them to further modify. Your first job would be to fix File References (take a look, can be shocking), etc.. After the file is as clean as you think it can be, then copy to create an entirely different version for modifying. Zip the original and keep. You may need it :-] Backup your files regularly. It is actually more difficult in some ways to fix and modify a converted file that it is to start over in 7, so work carefully.

[alexliz]

Excellent post, Fenton! Many thanks. It's a real treat to a 7 newbie, and I much appreciate the time you took to put it together. I will proceed as you suggest.

Alex.