5 Replies Latest reply on Jun 27, 2011 8:40 AM by philmodjunk

    How to update a database after its deployed to several users

    DianeJohnson

      Title

      How to update a database after its deployed to several users

      Post

      I have been building a database solution for about 4 months now and am ready to deploy it to several users. The thing is that every user will have unique database records. Before I deploy it, I want to make sure I have a plan in place to update the database layouts, tables, etc, prior to sending it out.

      So let's say I have a user that reports a bug, ie a script that doesn't work correctly or something like that. Obviously that will affect everyone that has a copy of the database. How can i fix the script and update each individual file? Or let's say, I want to add a feature to the database that adds new fields to a table, changes a layout, or adds a layout? How can I update each database with these new features? 

      For the life of me I can't figure out how to do this? Do I need to send out a new copy of the database, create some scripting to import the records from each table of the original database? Is there an easier way?

      Thank you.

      Diane

      P.S. Fairly new Filemaker developer (about 6 months now)

        • 1. Re: How to update a database after its deployed to several users
          philmodjunk

          There are two methods developers routinely use. You've hit on "method 2". "Method 1" reduces the need for "Method 2" but it is still needed from time to time so it is a good idea to structure your database to support both methods.

          Method 1.

          Split your file into two files. File 1 stores all your data tables. File 2 stores the interface--the layouts, scripts, value lists etc that control what the user sees and interacts with when using your database solution. With the system split like this, most updates can be deployed to your users by simply sending them a new interface file. Since the data file is left unchanged, they don't have to import any data and can just replace the old interface file with the new copy.

          See this link for more on this:  Convert to Seperation Model

          Method 2.

          Sometimes you have to change the design of the data file and then you have to import the data from the old file into the new. Before you deliver your files to the customer, include a "prepare for update" script that moves from layout to layout whild doing a Show All Records on each layout until this has been done for every table in your file. Then, when the time comes to deliver an update, create an import script in your new data file that performs this "Prepare for update" script in the original and then imports data from each table in to the new file. Your script should also include code that updates the next serial value settings on any serial number fields so that no duplicate serial numbers are generated the first time the user creates a new record after updating their solution with your new file.

          • 2. Re: How to update a database after its deployed to several users
            DianeJohnson

            Phil,

            Ran into a bit of a snag with this. All was working fine, I got the tables split off from the layouts and scripts. But now, when I add a record, one, I can no longer navigate to it using a script to go to related record. The record seems to show up in one portal just fine, but I cannot delete the portal row now. What do you think i broke?

            • 3. Re: How to update a database after its deployed to several users
              philmodjunk

              Deleting a portal row does not require Go to Related Records so I'm a bit confused by what you describe here.

              Being able to delete a portal row is a setting you control with Portal Setup...

              If you use Go To Related record to pull up this record on another layout and then delete it, (Do this with extreme caution or you may end up deleting records from a completly different table!) you'd need to look at the layout names and table occurrence names specified in the Go To Related Record step to see what has changed.

              • 4. Re: How to update a database after its deployed to several users
                DianeJohnson

                I am trying to create a custom access profile. I have split my database into two files. One for the Interface, Layouts, Scripts, etc. One for the Tables (Records). Now when I attempt to reduce some of the access for one of the user accounts, I will not access any of the table in the external file. I want to restrict access for one user to one specific area of the database and basically two layouts. The initial Home screen layout, and the layout that is to access one table of data. As soon as I do this, it fails to see any of the tables. I have a feeling there is something special about granting access when you have data in an external file, but I can't seem to figure it out. 

                • 5. Re: How to update a database after its deployed to several users
                  philmodjunk

                  With you files, you have to manage access privileges for both files in concert. When you open the interface file, references to the data file will cause FileMaker to open that file and it will attempt to open the file with the same account name and password used to open the interface file, but the privilege set you define in one file is separate from the privilege set you define in the other. Thus, in your shoes, I'd check for any inconsistencies between the security options specified in privilege sets of the interface and data files.