FM5/6-FM 7: FM7 Developer Needed? FMRobot?

[danabase]

I have a multi-file system running on FMP Server 5.5 with FMP 6 clients. I want to upgrade these files to 7, and have some basic questions. I've seen various options for some of them, but no pros versus cons answers. Here are my questions:

1.) To develop a system in 7, do I need developer? If so, what are the benefits? I do not need to bind the solution, which I know was something the earlier versions of FMP did. Also, if a system will be served off of 7 Server, does that make a difference to development in client versus developer?

2.) To use FMRobot, do I have to own developer or server?

3.) If $$ is an issue, and the files need to be converted manually into tables (except a main file), is this where time lies:

a.) Any relationships between files need to be redefined manually using the FMP 7 standards, which are different from 5.5 standards.

b.) Fields with calculation definitions would also need to be checked and redefined using the FMP 7 standards, as many of the definition criteria have changed with the new version. The time to complete this part of the conversion is directly related to the number of files in the system, the number of fields in the files, and the relationships between the files.

c.) Many of the scripts from FileMaker 5.5 will not translate in FileMaker 7. Those scripts need to be reset to use the script steps available in FileMaker 7. This includes script steps like Page Setup, Import, Export, Find, and Sort. Any scripts using these steps would be

[stanley]

Dana:

1. You do not need Developer to build a system in 7; the benefits are the Script Debugger (very very helpful) and other developer's tools, none of which are Absolutely Necessary, but which are handy, and make things easier on you. Considering that you will be converting what sounds like a fairly complex system, I would recommend FMD, for the script debugger and Database Design Report utility. Developer is only essential if you intend to create run-times or kiosks, special things like that. The fact that the system will run off Server doesn't change your developer experience.

2. I believe FM Robot will run on regular old FMP.

3.

a: The relationships should convert automatically.

b: You certainly have to check your calc definitions, but for the most part they should convert automatically. I agree with your statement that the more complex the solution, the longer it will take to check all of this out.

c: Some scripts will indeed need to be re-examined, and you will certainly have to redo some page setups and the like. However, much of it will convert cleanly.

4. Multiple files are what you'll get if you convert using FMP. To make a multi-file system into a single-file multi-table system you need a tool like FM Robot.

In the end, I think you'd be well-advised to spend the money on FileMaker Developer. If you're doing the conversion in-house it will speed things up and help you spot errors and problems. As far as FMRobot is concerned, I haven't used it, but I haven't heard anyone cursing it out, so I'm sure it works fine.

You should look at the migration documentation on FileMaker's website. There is an excellent checklist in one of the files which will help guide you cleanly through the process, and which will alert you to the pitfalls...

-Stanley

[Fenton]

2. Currently you still need Developer to use FMRobot, at least that's what their web site says.

3. a. Relationships will convert. But they will convert just as they are in 6. In 7 you can see your File References, which are the target file references of relationships. Unless you've been very careful, these will probably have many extras, duplicates from when you changed that server, and others. These superfluous file references are one of the main reasons converted files may seem sluggish compared to built-from-scratch 7 files. You can fix them manually, by making them all the same. But to remove duplicates you have to chase them down, in relationships, in scripts, in value lists, etc.. Tedious.

Or you can fork out some $ and get MetadataMagic (how much depends on how many files, $200-$300). It's an analysis tool for FileMaker 5-6 (not 7 yet), and is the only one which can fix and consolidate these file references.

Of course the above doesn't pertain if you move most of these files into tables in one file. In that case you'd be redoing the relationships anyway.

Personally, I would think seriously about putting files that have a lot of interaction into one file, using FMRobot for the fields, if you have a lot (otherwise just create them). Then rebuild the relevant scripts, sort of from scratch. Because you can build what we thought of as "multi-file" scripts, with external scripts, all into the same script in 7 (even if the files are separate, all you need is a Table Occurrence on the current file's Relationship Graph).

If you convert your existing files to 7, then intelligently use them to rebuild a duplicate structure mostly from scratch in 7, you will get the best result. In other words, convert them, but mostly to use for logic patterns and "parts."

Use the old files for such things as scripts which would be the same (but many are no longer needed in 7), and for copy/pasting layouts (big time saver). If you go to your old file and rename its table occurrences to match those in the new, you can import many things with no (or few) problems. If things don't quite match up, 7 will often /*comment out*/ what doesn't work, making it not so hard to fix.

Purists may say to do everything new from scratch. All I can say is it's good work if you can get it, but it would take a lot longer.

If you just convert as is, you may get usable files, but you will not get really good files, and you'll still spend a fair amount of time fixing little problems.