On 7/23/07 5:20 PM, "Peter Payne" <[EMAIL PROTECTED]> wrote:
> Also, if I do try to rebuild the file, is there an automated way to > import fields and scripts from the converted old databases? I am using > 8.5 Advanced. You can convert all the files to .fp7 files, then import the files as new tables in your new system. Something to watch for that I found disconcerting: Importing fields from the 'older' tables imports their options, such as lookups. If you decide not to use lookups for the field (and I rarely do anymore) and turn them off, the 'ghost' of the former option definition still remains. I don't know that this is a problem, but when I run Inspector, it always reports errors for these fields because they formerly had lookups and no longer do. I haven't had a problem with the fields, but wonder if the 'residual' data may cause a problem down the road. You'll find your scripting is much simplified when building a true .fp7 solution. You may have needed basically the same script in each of your former files, but now one script can perform the same task for each of many tables, based upon script parameters or whatever you choose to differentiate behavior. I posted a sample file a few days ago <http://homepage.mac.com/applesaucepro/FileSharing2.html> that shows using one main print or export script, which employs subscripts for finds, sorts, etc. and it produces over 150 reports. Overall I think the logic is easier to follow in a .fp7 solution. Finally, you may want to consider The Separation Model (TSM), which separates the interface from the data as much as possible. If you can employ this method, you'll find interface changes for user requests much easier to deploy as you only need replace the interface file, not their data file(s). HTH, Michele -- Michele Olson AppleSauce Productions, Inc.
