1 Reply Latest reply on Feb 21, 2012 1:03 PM by philmodjunk

    Best practices question



      Best practices question


      Hi, I have a question about a problem I am having regarding my use of both FileMaker Pro and FileMaker Server simultaneously. I posted this on both the FM Pro forum and the FM Server forum because it involves both. Since you cannot use both prgrams on the same computer I have each on a separate computer (FM Server is set up all on one machine in the single machine configuration and FM Pro is installed on its own computer as well). My issue is that I am the database administrator so I am the sole person to make changes to the database EXCEPT for on one layout protion of the database where some users have the privilege sets allowing them to edit and change the layout and its records. I cannot make changes to the database through the Server computer since that is just a host computer with just the Server interface so I use the development machine that has FM Pro on it to make changes. However, when my other users access the database they are accessing the one that is being hosted on the Server computer (users access my database from remote locations and none use FM Pro software, I launch everything through Instant Web Publishing).

      Currently, whenever I make changes to the database I save the file on the development computer using FM Pro but when the other users make changes to that particular layout and its records they are only changing the records/layout in the file being hosted by the Server computer. I am trying to figure out the best practice method for avoiding losing information by saving time/effort as well because I will either have a database with only my changes on it or only the users changes on it and I need both without having to physically replace the files back and forth between the two machines every time.

      I was thinking of putting the layout that other users can configure in a separate file altogether and creating a link to that file rather than my current setup of having a link to the layout within the same file but I have never done this and it raises many other questions and concerns of compatibility/user friendliness. I am sure there is a proper way to manage changes and have congruity between the FM Pro and FM Server computers but I just don't know it yet. Please help! Thank you!

        • 1. Re: Best practices question

          The safest way to update a hosted file is to make the changes on a copy, test them, save a clone of your file (no records), then take your databae off line so that it cannot be accessed by the users, import the data from all tables in the old copy into the new, update the next serial value settings on auto-entered serial number fields and then bring it up on the server so users can access the file.

          It IS possible to make design changes via your copy of FileMaker directly to the hoted file, but this is a lot like repairing a car's engine without turning it off. It can be done, but there are significant risks to your file's integrity and the data stored in it. Just opening certain dialogs in Manage | Database can lock a table so that all other users and any scripts they perform are locked out of that table until you close the dialog. Commiting changes to the table design will also lock the table while it updates. Scripts that modify data and that also use Set Error capture can thus run with apparent succes but leave records that should have been updated unmodified and your users can likewise get error messages back when this happens.

          You also risk creating problems for you users if such a change introduces an error on your part and they trip over it before you have a chance to discover the error and correct it.

          Much worse is the fact that a "network glitch" during the moment a structural change to your file is committed can produce a damaged file and while such damage is usually immediately apparent, there have been cases where the damage went undiscovered through many days and many backups before the file became unusable.

          Small adjustments to a script or layout do not seem to carry this risk and I do make such quick fixes on my hosted files from time to time. I also have a system that makes a lot of backups and I often test such changes on a back up copy before making them to the "live" database.

          To minimize the need for importing data into updated copies, developers often divide a solution up in to multiple files. This can create issues with how they manage security settings but nothing that can't be handled with server side authentication or scripts designed to "sync" account changes amongst multiple files.

          A frequently used way to split your file is to make two parts, a "data" file that stores all tables and an "interface" file that stores all layouts, scripts, value lists, etc. Since many changes to the design of a file update an interface feature, this method makes it possible to quickly replace the interface file with a new copy and not need to import any data.

          For more on this data separation model: Convert to Seperation Model