Alerts

Errors

Errors occur in FileMaker solutions when you've built a Calculation or script that relies on other elements in the solution, but then you later delete those other elements.  Now your Step can't go to that Layout any more because it doesn't exist, or the Calculation is broken because it was using a Custom Function that doesn't exist.

The options for fixing errors depend on the issue.  Do you still need this script to work, if so, could it use a different layout, or do you need to create a new one?  What result were you trying to get out of this calculation, and can you fix it without that Function or does it need to be added back?

BaseElements can't tell you specifically how to fix an error, it will depend on what you're trying to do and then how best to accomplish that.

Warnings

BaseElements Alerts can also include Warnings about issues in your solution.

Warnings are any situation where there isn't anything structurally wrong with your solution ( these would be considered errors ), but where there are situations that may cause unexpected behaviour or just make life difficult. Examples of warnings are :

• Using fields in a relationship join that are of a different field type. You can relate a number field to a text field in FileMaker, and it will work, but occasionally it will give you unexpected results. You can also do it deliberately to achieve specific results.
• Having an Account that requires you to change the password on next login, but the Privilege Set doesn't allow password changes.

Warnings are a useful way to see what might be an issue when a solution doesn't behave as expected. Not all warnings should be fixed, but you should be aware of what the warnings are and what is involved with them.

Performance Issues

Performance issues are harder to identify in static code, but there are a few that BaseElements can pick up that are obvious issues when designing a solution.

For example a relationship with multiple predicates should have them in order of increasing complexity so that the fastest ones are resolve first, and that you should not have redundant criteria ( for example a relationship to a set of invoice items doesn't need the customer ID as well as the Invoice ID as the invoice ID will cover all of the items anyway.  The customer ID is redundant. )

Also in relationships, using joins that are < > ≤ or ≥ will be much slower than fixed criteria, even if you have to gather a list of record IDs beforehand using another method.