(Running FM7 Dev on XP) I'm creating a runtime ap for distribution to A LOT of different end-users at A LOT of different companies, all Windows based distributions. Plan on issuing product updates over time which would include additional fields, tables, calculation & GUI, but would not change any existing fields or calculations.

In researching whether to separate the data from the application, "Using Filemaker 7 Special Edition" recommends a separation strategy in general (pg. 204), while "Filemaker 7 Bible" argues for keeping the data together due to potential issues with identifying the location of the datafile's filepaths on various systems.

Which way is better?

Is it likely to be easy to update the ap to my clients in the future if the data is not separated?

Thanks.

P.S. Due to its potential importance, level of complexity and lack of established "Best Practices" for FM7, this question is re-posted on the FM Developer Forum page.

If you are adding fields to the database then you'll need to change the data layer as well as the interface layer, so a separation model will have no advantage.

Probably the best bet is to put your effort into automating a system that imports the data out of the old solution and into the new solution in a repeatable and reliable manner.

So you're saying ditch the separation model. Correct?

Trying to think creatively here ... Would a logical shortcut to building a complex export routine be to 1.) Prompt the user to backup all data before updating ,then; 2.) Import the backuped data into the new update?

You would, of course, want the user to back up their data before updating anyway. So why not take advantage of that routine?

Yep, that might work. But it'll have to be pretty bullet-proof so it works with any user.

I'd prefer to make a system where the user only has to do ONE thing, maybe run an "update" script in the new database.

Even better, distribute the new solution in such as way that when it's first opened it *prompts* the user to locate the old solution and automatically perform the import without any further prompting.

I tend to avoid the export-a-file-then-import-the-file thing, and just import the data from the old FMP database directly into the new FMP database, no intermediate export files necessary.

Vaughn,

I find your idea an intriguing one. Is there really a way to do what you suggest?

I'm now at the point (months later from my last post), to where I need to agressively address this issue.

How exactly would I implement your suggestion? What would a sample script look like that might work on a runtime ap?

I know its been a while since this topic was last discussed, but I'd appreciate hearing again from you on this issue.

Thanks,

Ron