After attending the FileMaker Developer’s Conference a couple weeks ago, we are back to looking to see if we can do a single file solution for our product, Studio Manager, in the near rather than distant future. Unless money starts falling from the skies and we can hire more help, we will still release a multi-file version with minimal changes first. We’ve been working feverishly on the single file version lately to see just how much work it is going to take to deliver this solution. It is a LOT of work.
Again, the quickest way to 7 is to plan, prepare, convert, fix what broke, enhance slightly and deploy. Since attending Filemaker 7 Bootcamp in July, this has been our target. We are well along that path in the testing and refinement stages now. We are still hopeful that we can get the multiple file version out by October 1st.
Here’s what’s involved to migrate to 7 the hard way without simply starting all the way from scratch:
1. Run the best version of your files through MetaDataMagic.
2. Clean Up the File References so your files will open quickly in 7. MDM can do that with auto-fix with a little manual tweeking using the program. It’s easy. Document and clean up passwords so that you can open the files at all in 7. You can always sneak back into the FM6 version to see what went wrong if need be. But this might require reconversion – a pain.
3. Use FMrobot to convert all these FileMaker 6 files to tables in FileMaker 7 within a single file: FileMaker 7’s holy grail. You’ll get all the fields but most of the calculated fields will be commented out. Once your relationships diagram is clean, most of the calculations will work by just deleting the comment syntax, but the calcs with relationship references will only work if the relationship names match.
4. Look at the Conversion Issues in MDM and clean up your FM6 files as much as you can.
5. Convert all your files to FM7 by dropping the folder onto the FM7 application icon (Mac) or blank FM7 window (Win).
6. You have no decent layouts right now in the 7 version just fields and raw layouts with no formatting, logical placement, color, tabs, buttons or value lists. Decide on screen sizes for the new layouts you need. I decided to go with 845 x 650. We are assuming 1024×768 minimum screens for Studio Manager 7. This is up from 650 x 500.
7. Import sample data file by file.
8. Create blank layouts and copy and paste in your old layouts. Increase their size as planned. You can duplicate layouts and modify when you’ve got several that are similar.
9. Come up with a table navigation script that can get you from one table to another (such as from Contacts to Jobs to Timesheets and back to Contacts). The script needs to keep track of the layout you were on in Contacts so that when you eventually return to Contacts, you come back to the same layout. This is not automatic as it was in FM6. We created a Tables table that has a field called LastLayout so that every time you switch tables, you write the name of the layout you are leaving from into this table. When you move to a new table, you lookup that table’s LastLayout and navigate to it. It works!
10. Come up with a scheme for layout navigation buttons. Control all layout navigation within the same table with a single script. This is possible using the script parameters. The minimal scheme would have the layout name as the script parameter in each button. The only problem with it is that if you change a layout name, all the buttons that point to that layout break.
11. Figure out how to handle the fact that you now have a single layout navigation button and a single Scripts menu for your entire solution instead of separate ones for each file. You’ll need to sharply limit what appears on these lists or they will be too long and cumbersome.
12. Organize, re-organize, color code and carefully name and label the elements of a huge relationships graph. As you go along, this graph gets bigger and more complex all the time. We didn’t really fully anticipate the size and complexity this graph would have as it gets close to full size.
13. After you’ve got your navigation buttons working and all the layouts you are sure you’ll need, your next challenge is to script it all. Remember, the scripts didn’t come over with FMrobot. You can import your scripts from your old files and group and name them so that you can keep track of everything. This is your chance to decide not to duplicate all functionality. In many cases you’ll need to modify the scripts in some way to get them to work properly.
14. Get a journal going to capture the problems you encounter, the changes you are making and the ideas you are getting, etc.
15. Start using the ability to write field comments and to comment within calculations as opportunities arise.
16. Stay alert to new ways of doing things that will save time or provide more value, but keep on task. Don’t let feature creep keep you from completing your version 1.0. Just note other possiblities as you go along. Only the best of the best ideas that appear to offer immediate rewards should be introduced into your development process at this point.
17. Test, fix and polish.
1 reply on “FM7: What it takes to migrate to a single file solution”
After reading the below link on a discussion about the merits of 7, I couldn’t help but wonder if the ultimate situation is not a single file, but TWO files, one for raw data, and one for layouts and structure.
What do you think of this concept? Is it doable?
Sep. 27, 2004 Database Recommendations
Lee Rydstrand wrote, “…FMP, even at version 7… still intermixes data and structure, making it a time-consuming, disruptive, and potentially dangerous process to transfer the data to an updated solution.”
While Lee’s statement is true in the sense that it is still possible to intermix data and structure in FileMaker 7, it is no longer true that data and structure *must* be intermixed. Beginning with FileMaker 7, data and structure can be easily separated: data can be kept in its own set of tables in one file, while the structure and business logic can be contained in a separate file which can be modified independently without posing any danger to the integrity of the data. When it is time to update the solution with new capabilities or business logic, the updated structure file can simply be substituted for the existing file. It will automatically use the existing data tables.