7 Replies Latest reply on Oct 18, 2011 7:52 PM by dataWolf

    How to handle System Administration fields ?



      How to handle System Administration fields ?



      Context :

      • I am developing an application that will handle more than 50 tables + 100 occurrences of tables (which means a very crowdie diagram)…
      • Each record in these tables, in addition to their normal fields, contains the same 20 “administration fields” which are there only for application and object maintenance.


      • From a system administrator point-of-view it seems very cumbersome to check in each of those tables if there are actions to be taken.
      • More, if a new administrative fields is required, I have to make changes in all tables and layouts that are already developed.

      Question :

      • Can I solve that type of problem with global fields ?
      • If not, is there a “traditional approach” to handle these types of problems ?

        • 1. Re: How to handle System Administration fields ?

          Can you give some examples of how you intened to use these "system administration fields"?

          Global fields are an option as are global variables and a separate utility table of admin fields linked via the X operator or used to load globals during start up.

          • 2. Re: How to handle System Administration fields ?

            The application will be use to manage all objects involved in an “Enterprise IT Architecture”: Information Architecture, System Architecture, Technology Architecture, Process Architecture, Organization Architecture.  We need to manage current and target architectures, plus all the projects (50 projects) which are responsible to deliver the change (new, modified and deleted objects), or the delta between the current and the targeted architectures over a 3 years period.

            Some of the “Administrative fields” are:

            • Z_Code_Dev_Phase
            • Z_Code_Dev_Status
            • Z_Date_Creation
            • Z_Date_Edition
            • Z_Date_Syst_Mgr_Approval
            • Z_Date_Syst_Arch_Approval

            The “Systems Architecture Groups” need to be able to trace which objects :

            • have a given development status
            • are waiting for approval
            • have been modified since their approval
            • are part of a specific project delivery
            • will be implemented by an “effectivity-Date”
            • are superseded by another object
            • Etc.
            • 3. Re: How to handle System Administration fields ?

              What I would like to do is something similar to the following:

              A table   “T_Record_Status”   contains all administrative fields + the 3 following fields:

              Record_Status_Id    ( Number) (Automatic sequencing number) identify a unique record in the table   “T_Record_Status”.   That number would be copy in each record of any table, as the corresponding reference  in order to be able to see the current status of any object when looking at the layout of that object.

              Table_From_Ref    (Number or Text ?)  The identification of the corresponding  table in order to be able to find it.

              Record_From_Id   (Number)  The identification of the corresponding object in the Table_From






              Obtained from the creation of a Record_Status



              Provided at the creation of a Record_Status



              Provided at the creation of a Record_Status



              • 4. Re: How to handle System Administration fields ?

                Unfortunately, an indirect reference to a related table, cannot be implemented as a relationship in FileMaker. Such a link could only be handled through scripting or a complex calculation that matches to all the related tables returning null for all table but one.

                The fields you've listed with a z prefix do not look like fields that should have global storage enabled as they would appear to apply to a specific record or group of records.

                One way to implement this is with an "admin" table and the following relationships:

                Admin::__pk_AdminID = Information Architecture::_fk_AdminID
                Admin::__pk_AdminID = System Architecture::_fk_AdminID
                Admin::__pk_AdminID = Technology Architecture::_fk_AdminID
                Admin::__pk_AdminID = Process Architecture::_fk_AdminID
                Admin::__pk_AdminID = Organization Architecture::_fk_AdminID

                This allows you to set up all your "z" fields in this common table and the various "Architecture" tables serve as "detail fields". For any given admin record, all but one of these relationships would yield a null result as there would not be a record in that table with that AdminID value.

                Note: I am assuming that each of these Architecture tables have a significantly different structure. If the fields defined in each are the same or nearly so, I'd put the records in the same table and use a "type" field to identify which Record is "Information", "System", etc. in order to get a simpler relationship as well as a structure that makes it much easier to produce a summary report of all the records in these tables.

                • 5. Re: How to handle System Administration fields ?

                  Thank you Phil.  Your time is appreciated very much.  I will have to think about it because it seem a little bit complicated to a beginner like me.

                  I believe I will continue the way I was doing until I get more acquainted with FileMaker Pro.

                  • 6. Re: How to handle System Administration fields ?

                    For a beginner, you've taken on a sizeable project.

                    I think your structure needs some work. I think you should have one table for Architecture with all those administration fields and separate child tables for the different Architecture types related to the main Arch table in a 1 to 1 relationship.


                    • 7. Re: How to handle System Administration fields ?

                      If these fields are generic to all the tables, you can create a table with all the admin fields, make them global. Then, for every table, make a relationship to the admin table that use the X join, that means it will match any value with any value (always a match). Now, from any table you can change any field in the admin table.

                      I think there used to be problems with relationships when you were in find mode but it appears to be fixed in 11. Also note that globals reset whenever you quit FM and restart. If you did not want that behavior then you could make them not globals, and create exactly one record in the admin table, and the values will persist after restarts that way.