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.
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:
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
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
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.
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.
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.
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.