Hello,

I'm well aware that this may be a newbie question, but I'm going to ask it anyway.

I've spent a good amount of time (about a year) developing a job tracking / scheduling / invoicing solution in FileMaker Pro 7 for our graphic design firm. Several other local agencies have tried it and asked if it's available for purchase. What I'm wondering is this: What's the difference, if any, between a FileMaker Pro "file" and a FileMaker Pro "Application"? Since the solution I've developed is not even a 1.0 candidate, I'm wondering how "upgrades" are handled for future versions. If the end user is using an "application" that's really just a file, how are upgrades handled? In other words, is the end user going to have to endure a painful process to migrate data to the new application, or is there an easier way to handle it?

Hope this makes sense. Thanks for your assistance.

-David

An application is usually an executable. A better word is probably "solution". Your FM files work together as a solution.

As to upgrading: You'll need to script the upgrade progress and it is a fair bit of work (scripted imports of data, resetting serial numbers, ...). Handling value lists especially is tricky.

Or you can try to separate the data from the "logic" through interface files. In that scenario you can just send your clients new interface files to replace the old ones. Setting this up is a lot of work too.

Either way, a lot of throught needs to go into this...

For upgrades to my solutions, I provided the customer with a clone of the database. The initial layout has an "Import" button inside a portal that only appears when there are no records in the database. The Import button then runs a series of scripts to go to the different tables/layouts and import the data based on matching fields. And as Wim advises, resetting the serial numbers is extremely important or you will end up with duplicates.

What I did for the value lists with custom entries is to actually use a table specifically for those value lists. The table has only one record with a text field for each "value list." The list then pulls from that field in the ValueList table. Otherwise, everytime you import in the existing data into the new solution, you lose all the recently added custom values in the list.

Mike