Yes, there have been lots of changes over the years. Probably the major ones include:
1) Tables vs. files. You've already mentioned this one, but it has huge impacts on how you design. You can retain your old one-table-per-file model, but ... don't. You can achieve huge efficiency gains by consolidating your databases down to one, two, or a few files (based on need). (Example: One old .fp5 database I had included a script for executing a menu selection. It printed out at 151 pages. After upgrade? 2 pages.)
2) Security model. Old model was passwords and groups. New model is accounts, privilege sets and extended privileges. Learn this new model well. It's the key to everything.
3) Data layer vs. interface layer. We've been given lots of tools over the years that allow us to move business logic out of the database schema (the Manage / Define Database dialog) and into the interface: Conditional Formatting, Script Triggers, merge variables. Use them. If you keep business logic out of your database, it's likely to run faster and smoother.
I've attached a couple of documents to help you with the transition. Good luck!
P.S. You may already know this, but you'll have to convert your .fp5 files up to .fp7 before you can convert them to .fmp12. So you'll need a copy of FileMaker version 7 - 11 as well as 12.
Thanks, Mike. This is great information. I'm fairly comfortable with the "new" tables model, but l need to dig into the security guide. I've done a little work in MySQL, so data vs interface makes sense. I'm looking forward to seeing how this is handled in FMP12.
See this article for some important things to look out for when converting your files.
Converting Old FileMaker Databases from FileMaker 5 or 6 to FileMaker 12
We’re finding that there are still several organizations using FileMaker databases that were created many years ago with the old version of FileMaker. A lot has changed over the years. The common file format was call .fp5 (Version 5 of FileMaker) but this file format lasted through FileMaker version 6. In 2004, FileMaker completely rewrote FileMaker with version 7 and changed the file format to .fp7. Version 7 was good until the release of FileMaker 12 in 2012. The current FileMaker database file format is .fmp12 and we expect that format will last for many more years to come.
Modern versions of Mac OS (after 10.6 Snow Leopard), no longer support running FileMaker 6 or earlier…and so this is forcing these databases to be brought into the newer file formats just to be operational.
So, if you have an old format database what do you do?
Straight conversion of the files may be relatively simple, but it doesn’t guarantee the database will retain all the functionality it originally had…and it certainly won’t be optimized for using any of the new features available. Taking advantage on these new features such as multiple tables in one file, new security, and fully relational capabilities is called databasemigration and can be a much more costly proposition. Many companies invest in creating an entirely new database and only move the data from the old database into the new solution.
That said, many people will want to at least try a straight conversion. This is a minimum of a three step process.
1. Run MetaDataMagic on the original database files.
2. Upgrade from .fp5 to .fp7 with FileMaker 11
3. Upgrade from .fp7 to .fmp12 with FileMaker 12.
One absolute key to conversion is running an application called MetaData Magic on your original .fp5 FileMaker database BEFORE you do the file conversions. (We have no connection to New Millennium Data other than using their product successfully in many conversion projects.)
NOT performing this step can leave you with A LOT of extra work later cleaning up old database references, etc. that could be completely avoiding by employing this utility. The “File Reference Fixer” removes unused file references that can cause issues in the converted files. It will also provide you with key information in the form of an error report that identifies what will likely need to be fixed once you convert.
PLEASE use MetaData Magic before converting your solution. You won’t be sorry. If you would like assistance in this process, we can complete this task for you at a minimal cost.
Converting v6 files to the new formats have some real gotchas. One involves file references. v6 files hold every external reference ever made. After conversion these are all revealed. It's not unusual to see 5-10 references to each external file (sometimes more). Each one of these will be used somewhere in the file - in define fields, scripts, imports, value lists, and so forth. This can be a real headache down the road.
There is a tool called MetaDataMagic, from New Millennium, which can consolidate all of these references prior to conversion. I strongly recommend that you run this process on your files, if you are going to be converting them. It can also flag other conversion issue for you. It looks like you can still purchase this. You might also consider having someone who's done a lot of conversions do this process for you - it could save you a lot of time getting up to speed on something you hopefully will only do once.
There's more than just structural or scripting changes. A major issue is whether or not a complete Rewrite is needed.
THere will be many issues to fix when upgrading from A to B to C. Also you might find that the spaghetti monster created over the years can be simplified.
A Rewrite will or should improve things and add new features, for instance reports have been greatly improved eliminating the need for preview mode in most cases (punny).
The he most important point is DON'T CONVERT THE LIVE DATABASE but convert a copy and test, test test.
WIth that in mind I would tend to want to do a rewrite.
You realize that you are responding to a 2-year old thread, right?
I do now. Guess I'll have to spend more time checking that very faint date tag. Thanks.
As a database guy I would use the ability to color really old dates to draw attention to them. What's that called, it's in some database program called...FileMaker, right?