Maintaining A Commercial Application

[jfarrell]

After just investing nearly $1,000 in FileMaker related products (Developer, Scriptology, Books etc.) I have discovered that is it nearly impossible to upgrade an end user's application once they have entered data. Since Layout and Scripts are actually stored in the database files, there is no easy way to distribute an upgrade of the application to an end user without a LOT of planning, hassels and import/export funtions.

Before I give up on FileMaker Pro 5 Developer, does anyone have any suggestions on maintaining my commercial application updates?

Most professional application developer languages maintain code separate from datafiles. FileMaker is great if your customer owns a copy, doesn't want any changes once it is completed, or they are willing to make the changes on their installed database.

[ April 13, 2001: Message edited by: Jack Farrell ]

[Kurt Knippel]

quote:

---

Originally posted by Jack Farrell:

Since Layout and Scripts are actually stored in the database files, there is no easy way to distribute an upgrade of the application to an end user without a LOT of planning, hassels and import/export funtions.

Before I give up on FileMaker Pro 5 Developer, does anyone have any suggestions on maintaining my commercial application updates?

---

What I did was a simple backup/restore routine. When upgrading the user would simply do the normal backup function (which I included to allow them to backup thier data) which wrote out a bunch of FMP files with just the data in it using the export functionality. They then installed the new version, which when opened checked to see if certain fields had been set yet (user name, region, initials, etc) and if not it assumed that they had a new version or reinstall of a previous version. It then asked them if they wanted to restore thier old data and if so prompted them for the location of the files. It then imported all of the old data.

All that this required between versions, was an updating of the import formatting, if there were any field changes. Once going I was able to pretty quickly and easily upgrade versions, and it could be performed by the end user.

Believe me this is not any more difficult that the same kinds of things in dBase or Access or whatever.

[jfarrell]

Hi Kurt. Thanks for the suggestion. The only problem that I can see with it is how do I restore Auto-Enter field values like the next Serial-Number or Record-ID etc. This feature has to be turned off during the re-import of the datafiles, but the next value needs to be reset before new data is entered. Do you have a work-a-round for that problem as well?

[ April 13, 2001: Message edited by: Jack Farrell ]

[Kurt Knippel]

quote:

---

Originally posted by Jack Farrell:

Hi Kurt. Thanks for the suggestion. The only problem that I can see with it is how do I restore Auto-Enter field values like the next Serial-Number or Record-ID etc. This feature has to be turned off during the re-import of the datafiles, but the next value needs to be reset before new data is entered. Do you have a work-a-round for that problem as well?

---

Turn it on. It will not Auto-Enter fields that already contain data, but does seem to update the serial numbers.