My step by step 6 to 8 Upgrade Instructions (muti-file to single file)

[Nik]

I was having a hard time finding any comprehensive step by step instructions to convert a multi-file FMP 6 system to a single-file FMP 8 system.

One of the systems I wanted to convert is very complex (60 tables, hundreds of scripts, hundreds of layouts).

Anyhow, I ended up writing my own step by step instructions while upgrading some of my smaller systems, so that when it came to upgrading the larger system, it would work much better.

I thought I'd share the instructions here, in case anyone else was interested:

FMP 6 multi-file to FMP 8 single-file

Theye've worked well for me, and I'm now on to the bug-fixing stage of this very complex system. Unfortunately, there are still a lot of very nasty bugs still to be sorted out, but that appears to be the case even when doing a simple conversion from FMP6 to FMP 8 (multi-file to multi-file).

At least these instructions provide an opportunity to move to the single-file model.

If anyone knows of any other step by step instructions, please post them here, as I'd like to see if there's a better way that what I've done (which is still a very complicated process).

[Fitch]

Thanks for sharing. I have a few comments:

1. It's not necessary to remove all security, but you need to be aware that any group with full access privileges will change its name to "[Full Access]" so anywhere that you use Status (CurrentGroups) to reference that group by name you'll have to manually change it.

2. Before you convert, I would strongly recommend using MetaDataMagic to fix the file references. This will save you a lot of time and headaches.

3. Check out the Tech Briefs at FileMaker.com for more info.

4. Adding capitalized name of file... is a good start, but I'd encourage you to go further and establish a solid naming convention. You're going to have a LOT of table occurrences, layouts, and scripts to keep straight once you put it all in a single file.

5. Think about your relationships before you get to far into it. You might think for example, that your old account::contact and contact::account relations can now be consolidated into a single, two-way relationship. True as far as it goes; however, your graph will end up looking like a mutant spider if you do this. Many developers today have moved away from the spider graph toward the "squid" graph, which is designed around separate functional groups on the graph, each with a "head" at the left and the tentacles to the right.

Just to recap, the condensed conversion order is:

Fields

Relationships

Blank layouts

Scripts

Paste layouts

Anyone have a good mnemonic for that?

[msadesign]

Fitch,

I was reading through as many posts as I can before I begin my conversion from 6 to 8.5 Advanced and came across yours. I wonder if you could expand a bit on the idea of a 'squid'?

As I am visualizing things, the key relationships that existed in 6 certainly exist in 8.5 so I can't really get a mental picture of what you are describing?

Thanks,

Michael