The DDR is an indispensable tool for QM of FileMaker Databases. Omissions in the data covered by the DDR reflect directly on lower database quality in these areas.
The DDR should thus be extended to supply information on the following topics:
- Layout View Settings (Form/List/Table, Default + Table Properties)
- Layout parts
- Tab order
This missing information in the DDR may seem like a small unimportant omission, but it has VERY FAR REACHING NEGATIVE EFFECTS:
Because this information is missing:
- the value of the DDR is vastly reduced - as are analysis tools which use the DDR, and
- ERRONEOUS DATABASES WILL BE DELIVERED TO ENDUSERS
- developers and endusers lose trust in the FileMaker Platform as a dependable database platform
- analysis tool developers are frustrated, as they are unable to help the situation
- Fields which exist solely for the purpose of sorting sub summary parts in layouts (and this is not uncommon), are marked in analysis tools as being unreferenced / unused - since their use in the sub summary part is not logged / not loggable.
- This can lead to such fields being deleted and removed by the developer in complete belief that the field is no longer in use in the database, which in turn breaks the report layout. (Particularly in large, old or ‘inherited’ databases, where the developer is unfamiliar with the databases functionality)
- However, because summary parts are not in the DDR there is no way for analysis tools to discover this error.
- The upshot of this is that such errors are almost predestined to be deployed and discovered by endusers of FileMaker databases
- And to check that a field is really not in use you must check every sub summary part in the database before deleting the field
- Form + List Layouts which still have all three default views can pose a security hole, where users can switch to table layout and add any desired fields
- There is no way to analyze this and find such layouts without looking at them ALL
- Layouts where the first field in the tab order is a non editable field pose a security hole: after a new record or duplicate record step the cursor is automatically placed in the field at position 1 in the tab order - EVEN IF IT NOT EDITABLE.
- The upshot is that users can destroy data that is meant to be read only - very often a central logo image, which is often the first object in the top left corner of the layout
- This occurs very easily and frequently, for example, when a new navigation bar is pasted into every layout.
- There is no way to analyze this and find such potentially problematic layouts
- If the developer wants to avoid this potential bug he has to check the tab order after every paste operation
- avoidance of he problems above
- higher quality error free deployed solutions
- happy FileMaker developers, happy end users, happy analysis tool developers, happy everybody
- Checking FM DB quality
- Removing old fields
- Avoiding bugs