Hi Jackie Will and Geoff make good points. Here's a different take on it.
Another option, when the client doesn't want a rebuild right away is to just convert the db's to v10. Small solutions go pretty easily but if your 100db's are part of an integrated solution things get more complex. My first was 122 dbs in a single solution with 30 users and very minimal acceptable downtime. MetaDataMagic (http://www.newmillennium.com) is indispensable in this process. It will do a solution analysis and has a Conversion Issues module that will ID nearly all of the problems that will occur post conversion. These include GTRRs between files without explicit screen refresh in the referenced files, print setup issues (primarily Windows), sorting issues, reserved terms etc. etc. etc. The other big issue is with file references as these can really slow down a converted solution as all the files look down every path that was ever set in v5 for related files, remote scripts etc. MDM has a File Reference Fixer (FRF) that sort a lot of that out. MDM is priced in numbers of files process at once - if your 100 db's are in one solution it gets expensive. If the files are isolated the pricing gets more under control - "A free downloadable demo is functional for processing 3 files at a time." It is then fairly straightforward to start merging "some" of the files - primarily those that are uni-directional in purpose - eg. for value lists, settings, names. Other files "talk" to them but they don't "talk" to other files. (City/Prov/Region/Country sorts of things), lookups and the like. When there is no user interface or scripting in these files it is fairly simple to create/import the table needed, import the data into it and then simply edit the associated file/table in the relationship graph. Files with lots of interface and scripting are not simple to do - at all. I have done 8 or so "just convert and make it work" conversions for various clients using MDM and the FRF. These ranged from 40 to 122 integrated databases. One useful side-effect is that the project can be budgeted as it falls into a number of phases - (1) Analysis, (2) Pre-Conversion fixes (Adding Refresh Window Steps that convert to Select Window and Exit Record steps where you need a Commit after a cluster of SetFields), (3) running FRF and doing the conversion to 10, (4) Post-Conversion fixes (window print settings) and deploying. At this point the solution is deployed and users are active. (5) Post-Conversion Bells and Whistles can be done later - satellite file merging, adding webviewers, PDF and Excel optioned exports and so on. Depending upon your "jam" level and the degree of mission-criticality of the solution you can do practically everything of the live system - FMP 10 is a gem for this. Failing that it is easy to import tables, copy/paste scripts etc. 1 and 2 can be one phase at $X, 3 and 4 are another at $Y and 5 is the third at $Z+(n*m). Here's something from a post on another list from Darren Terry. <start>..................................................................................................................................................................... 1. Before doing anything with the scripts in the old files, define all of the needed layouts in the new consolidated file (the destination file). Define **blank layouts** named the same as the layouts in your other files -- make sure the names match -- and make sure that they are based upon the corresponding table occurrences on the graph (which should already be defined by this point). 2. In each of the files that you're consolidating, prefix the script names with the name of the file, so that scripts in the People file begin with the word "PEOPLE". This way, all buttons on the layouts in those files get tied to the proper, renamed scripts. 3. Now import the scripts into the consolidated file. This way, all the scripts end up logically grouped by file. Don't worry -- you can rename them later and re-organize them in whatever way you want. But for now, by renaming the scripts with the file's name as a prefix, you avoid the inevitable confusion of having like-named scripts in different files. 4. Once the scripts are imported, now you copy/paste the contents of your layouts from the external files into the corresponding layouts in the target file. By defining blank layouts that are named the same first, you prevent any layout references in the imported scripts from breaking. By waiting until after the scripts are imported before you copy/paste the layout contents, you avoid buttons on those layouts from breaking. Remember that FMP maps layout and script references by name, not by ID, so by doing it in this order, you avoid breakage. Once all the scripts are imported and all the layouts are copy/pasted, you can rename your scripts and reorganize them as you wish. regards, Darren ****************************** Darren Terry [email protected] Pacific Data Management, Inc. http://www.pdm-inc.com/ <end>..................................................................................................................................................................... Anyway - this is another option for you to consider...btw FMP10 Advanced is exceedingly useful in this process. Really useful! Stephen ---------- "The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair." - Douglas Adams On Jan 5, 2010, at 2:22 PM, Geoff Graham wrote: > To add to Will's response, you might want to go through your field > definitions and relationships in version 5/6 before you convert, and clean > any non-alphanumeric chars and spaces in those names. The conversion process > will comment out questionable calculations that worked fine in 5/6. Not only > is it difficult to track these down in 10 in the first place, fixing > field/relationship names after the fact won't then fix your broken > scripts/calcs. Do it in 5/6 where it still works and it will change it > everywhere it is referenced, then the conversion in 10 will beautifully match > everything up. Personally, I go for ODBC compliant names - you might be glad > you did someday. > > After converting you can now see all the obscure file references 5/6 may have > inserted into your files. (File:Manage:External Data Sources) I change all > these to file:filename.fp7, as everything I do is always in the same folder > or same server, and simple relative links are usually best. > > A couple of gotchas in scripts: > > Go to Related Record no longer necessarily goes to the first related record. > Sort no longer resets the current record to the first in the found set. Any > script that then loops through the found set may not start on record number > one like it always used to. I insert Go to Record [First] at the beginning of > all these scripts. > > In 5/6, a script that calls another script in another file, and ends there, > would leave that file as the frontmost window. No longer. You'll have to > insert Refresh Window [Bring to Front] at the end of these kinds of > navigation scripts to insure the target window pops to the front like it used > to. > > just those things can save you 95% of the headaches sometimes involved in 6 - > 10 conversion. > > btw, FM10 runs just fine on 10.4, but I think they'll want you to get up to > 10.4.11, which shouldn't be a big deal (free upgrade), unless you know you > have other software that won't handle it. > > good luck, > Geoff > > On Jan 5, 2010, at 3:31 PM, J. wrote: > >> Odd simple question for this expert group, but I have at least 100 db’s that >> I’ve developed on FMPro 5.5, and (obviously) need to upgrade to a newer or >> newest version of FMPro –possibly advanced. >> Question: How many other versions do I need to use to convert these without >> manually(!) converting all of them? >> >> If it matters, I’m a Mac user with OSX 10.4.4 and also will be needing to >> use it on my laptop with a newer operating system. >> >> Thanks! >> Jackie
