Version 1.0.5 and later of BaseElements added the option of a "Warnings" tab to detect issues that may or may not be problems in your solution or may just be issues that you'd like to be aware of.

Warnings are different from "Errors" in that an error is an obviously broken function in the database. A warning comes about, not because something is broken, but because it will work exactly as it is setup, but there are obvious reasons why the setup might not be what was intended.

The best way to use the warnings function is to look at this list on the setup, and see which of the errors you want to view and or look at, and turn some on or off depending on your development style. From there you can identify which ones are obvious fixes and should be looked at straight away, and which ones you can leave, and only address if they come up as an issue later.

Below is the explanation and details for each of the items that are currently warnings in BaseElements.

---

FileMaker Warning Issues

These are issues that are related to the functioning of FileMaker, not the output of the DDR.

Account Empty Password

This means you've setup accounts that have no password. Although not always an error, i.e. the default file option creates an Admin account with no password, in larger solutions with multiple accounts this isn't best practice.

EA Account requires Change Password

EA Account allows Change Password

The External Authentication process doesn't allow the user to change passwords, so trying to enforce the "Must change password on next login" will cause issues, or allowing the user to change the password will also cause problems.

JoinPredicate Field Mismatch

This means that a "Join Predicate" - otherwise known as the lines matching one field to another in a relationship - are not using the same field type. This may or may not be deliberate. For example to match on a non-contiguous list of dates, you'd need to put the list in a text field and match the other side to a date field. However it's often the case that a field match from a text to a number that is done by accident will give unexpected results.

ScriptStep Disabled Errors

This warning is to alert you that a script step that has been disabled but has errors in it. Enabling the script step will cause the broken steps to be active, and this may cause problems, or have unintended consequences.

ScriptStep Modifying Calc Field

This is a simple one to catch, and a good thing to check for. It means you're doing a Cut, Paste, Clear, Set Field, Insert or Replace on a field that is specified as a Calculation or Summary field.

In other words, you're trying to modify a field that can't be modified.

TableAccess Delete No View

This means you have setup privileges in such a way that you can delete records that you can't view. Which means you can't even tell what you'd be deleting when you tried to delete it - which you'd be allowed to do.

Table With no TableOccurrence

Without any TOs for this Table, it is effectively not able to be used anywhere. You could either remove the Table if it's not required, or add some TO's if you plan to use it somewhere.

Table with no Layouts

This may not be an issue and may be deliberate, as you don't need Layouts for all functions, but some functions do require Layouts, and this may cause issues.

ValueList PrimaryField Unindexed

ValueList SecondaryField Unindexed

The Primary Field in a ValueList always needs to be Indexed. This will happen when you first create the Value List. If this isn't the case, the ValueList won't work, and your list will show no data.

However it is possible in some circumstances to have a ValueList using a secondary field that isn't indexed. If your value list is set to "Sort values using : First Field", then the second field doesn't need to be indexed. In fact in that case the second field could be a global or unstored calculation.

However if you sort using the second field, or show only values from the second field, then both fields need to be indexed for the ValueList to work.

Unrelated TOG on Layout

This means you've added a field to a layout where the TO of the field isn't accessible from the TO of the layout. In other words, the field will show on the layout as "Unrelated Table" and won't show any data.

File Reference Points to Itself

This means you've have created a file reference which might be pointing to itself. To get rid of the file reference you need to change all of the objects that use this file reference to refer to the objects directly so this file reference is no longer required.

If this is a different file you may want to consider changing it to a unique name to save confusion.

Sorting from a disconnected TOG

This means you are trying to perform a sort from an unrelated table occurence. You should remove the sort or change it to a different table occurence.

---

DDR Warning Issues

These are more "Alerts" than warnings. They are to point out issues in the DDR where either the data is incomplete, or there is inaccurate information in the DDR.

ScriptStep XML Fields Missing

ScriptStep XSL Fields Missing

These 2 are related to bugs in the DDR output. In the options for importing and exporting data, there is an option for exporting as XML, and for processing that XML before or after with an XSLT file. You can also set the file to use in both circumstances by a calculation. However any fields, custom functions or other items that are used in that calculation aren't included in the XML output by the DDR.

So in effect a field used only in this place and no other would be listed as "Unreferenced" by BaseElements, when in fact it is in use.

This has been submitted as a bug to FMI, so I expect that it would be fixed in a future version.

ScriptStep GTRR Layout

If you've used FMP in a multi-file solution you may have come across this one. When you do a GTRR script step, but you're using a TO that is based on a Table coming from a different file than the layout, the layout shown in the script doesn't appear correctly.

For example, in a separation of data solution, your GTRR is going to a layout in the current file (the interface file). The TO for that GTRR is in the current file, but the Table that it's based on is in your data file. In this case although the specify dialog will show the correct name, the script itself shows the name incorrectly.

In all of the cases, BaseElements will pick up the correct layout and use that for it's reference. However the data reported in the DDR is affected by the same bug that affects the script display, so it doesn't always show the right information.