Updating Database

[stevo]

Although this question may partially have a technical nature to it, it's seemed logical to ask it in this forum.

My question is how do you logistically update a FM database (ie: add features, fix bugs, improve layouts), when both the data and the code are married to eachother in the same file, and your client is using the database at his office, but you want to work on it at your office.

My last experience with database developement was with dBaseIV (remember that software?) and the program code was separate from the database file, making it possible to update the program code while your client is still using it and adding records to the database file.

Do you have to create complex import scripts, so every time you bring a new version to your client, it imports his current data. And if so, what about fields with an auto entered serial number. How do you know where it left off.

Any insight would be appreciated. A solution here would certainely fill a major gap in my understanding of how to develop for clients.

[ June 03, 2001: Message edited by: stevo ]

[Chuck]

There is no easy answer to this, and it is one of the major limitations that FileMaker imposes on developers. However, there are things that I know of which can make life easier for you.

Assuming that you already have a solution developed, one way is to do everything manually. Honestly, this is what I do most of the time, because I haven't yet standardized an update routine in my solutions. Something I keep meaning to do. I develop with a version on my local machine, make any changes necessary, and bring those changes to the client's machine, manually importing the data into the new version of the database structure.

I did build a solution once that automated as much of this process as I could, but one thing it couldn't automate was importing the data into a database that contained new fields. This is because the import script step saves the import order, and could only be updated manually. I did try to provide a safeguard for this, so that the script wouldn't work if the fields had changed. This was on a Mac, so I used AppleScript to determine what the list of fields was for the new and the old versions, and if that list differed (after being sorted), then the script wouldn't continue.

Basically, that technique was to do a save as of the old database, naming it Database_OLD.fp5, to a save as of the new database, naming it Database.fp5 and importing the data from Database_OLD.fp5 into Database.fp5, after having performed a Show All Records. I then used AppleScript to delete the old version from the system.

Resetting the serial numbers is not straight forward, but it is possible. Check out www.databasepros.com for a solution on this one, or you can use the DialogMagic plug-in. In the pure FMP solution (no plug-in), my new database would have the serial number set to 1 for the next new record. I would then create and delete records until the newest record's serial number equalled the largest serial number in the database. If I'm not mistaken, FMP 5.5 may have a feature that allows this to happen more easily.

I too would be interesting in hearing what others have found to make this work.

Chuck

[Anatoli]

I am usually working through Internet for clients; layouts, scripts etc.

BTW, I am ex-dBase man myself.

You can set your solution with more databases for each task. I would not say, that complete separation of data and programs can be made, but to some degree yes. It involves relations and it is possible.

[JPaul]

I agree with Anatoli: in FM the separation between code & data is hardest to do rather than other integrated environments (such as MS Access or Visual Dbase) but, doing an extensive use of relations and scripts, it is in some way possible (with or w/o plug ins).

Regards

[Anatoli]

One will appreciate the "separation" if you must run the solution over slow (33-64k) lines.

Because "on the other side" you need just raw data without layouts, you can use all tricks to get reasonable good performance.