1 Reply Latest reply on Mar 13, 2012 3:42 PM by philmodjunk

    Data Separation Model Best Practices



      Data Separation Model Best Practices


      I am finishing up my multi-user app in a single file model.  I'll soon be ready to start the data separation process.  I would love some input on issues and best practices others have experienced.  Here are a few things I've gleaned from the Forum:

      1) As long as the user security information is kept in sync, users should only have to logon once to access both files

      2) $$ global VARIABLES do not cross the file boundaries.  I should convert all of them to global fields to be safe. True?

      3) To separate the code & data, I make 2 copies of the file then change the data source in the relationships graph then clean up

        Question: Is there a way to make the data source dynamic/selectable?  I'd like to be able to use different data sources for different clients.

        Question: Are there best practices around where the relationships are stored (code or data files)? Performance issues with either?

        Question: Do I have to do this all over again when I move everything to a server-based model?

      Any other cautions or best practices you'd care to share?



        • 1. Re: Data Separation Model Best Practices

          1) essentially correct, but if you have a script that has the "run with full access" option enabled, this option enables full access interaction with the current file but not another file such as the data file. In some cases, a script defined to run with full access privileges must be defined in the data file and performed from a script in the interface file in order to run with proper access privileges.

          2) No. With table occurrences defined in the interface file, the variables and most scripts all are part of the same file. Global variables are an option for any scripts that must execute in the data file, but values can also be passed as script parameters.

          3, Q1) no, but it's easy to set up one copy of your system for one client and a different copy of the files for another.

          3, Q2) Some relationships must be defined in the data file if there are calculation fields that require the relationship in order to evaluate correctly. Most if not all relationships must be defined in the interface file or the scripts, layouts, value lists, etc. will not funciton correctly. You'll need to analyze how each relationship is used to determine whether it is required or not in the two files.

          3, Q3) Most files designed for use in FileMaker Pro as a single user file can be used with little or no changes when hosted by FileMaker Pro or FileMaker Server. With all such files, there are some issues that have to be checked, in particular the location of any "by reference" inserted files may need to have their references updated after the move and global fields function a bit differently in multi-user systems. Data Separation files have the same potential issues but nothing in addition IF both files are hosted from the server. If you install separate copies of the data separation file on each client machine, then the external data source references in the interface file will need updating in order to find and access the hosted data file.