2 Replies Latest reply on Mar 17, 2011 8:56 AM by philmodjunk

    Filemaker...life after launch of the new databse...

    Vinny

      Title

      Filemaker...life after launch of the new databse...

      Post

      So I created a database, and many people begin to use it in my office.  And oh! I found a bug.  or Oh! I should have added that feature. Or Oh! it would be easier if we...etc etc.

      Anybody have any good articles or materials on how to manage your DB after you launch?

      For example, I'm tryin g to understand how to update the file, and re-launch it after making my changes or fixes without losing any of the data that was entered during my development time.

      Example: we found a bug in the DB.  Do I make a copy of the DB, edit it, then copy it back to the networked location? (dedicated machine on our LAN).  Can I merge changes since?  How do I handle this?

      Thanks in advance for your help!

        • 1. Re: Filemaker...life after launch of the new databse...
          Sorbsbuster

          Rule 1 would be: do not work on the live, running, shared file.

          Before you do any more work, make your next task to write an import script that cycles through all of the tables and 'Show All Records'.  Then in the upgrade file have a script that runs that script in the 'old' file, then in itself runs an import script to import all of the data, table by table.

          Take a copy of the current file (if you don't already have one, which would be better)

          Take a back-up of that file, and date it.

          Do your development work on the first copy.  Make sure it is not available on the network, or people will accidentally log in to it.

          When you want to do another upgrade release, make a clone copy of the file you have developed, take everyone out of the working file, and run your import script on the new file.  Rename the new file as the correct current-file name the users are used to.  Rename the 'old' file with a date appended and store it well away from where any users could possibly see it.

          That's my suggestion, anyway.

          • 2. Re: Filemaker...life after launch of the new databse...
            philmodjunk

            Such an import script should also update the next serial values settings on all fields that use the auto enter serial number field option. There's a script step, set next serial value that you can use for that. You import data from a given table, determine the largest serial number value in the imported records and then set the next serial value to a larger number than that maximum.

            You can also avoid the need for importing all togehter if you use a data separation design. You put all your tables in one file and keep your scripts, layouts, value lists etc in the other file. Since many updates, changes, corrections only change the interface, those kind of changes can be made and deployed simply by replacing the interface file with a new copy and then no data importing is required.

            It's not terribly difficult to split an existing single file solution into two such files either: 

            Convert to Seperation Model