Troubleshooting FileMaker PHP Issues

The team at Insightful Systems also develop web based interfaces for FileMaker databases. This allow our clients and their end-customers to access FileMaker data across the Internet via a web browser. As with most new skills, there was a learning curve that required a degree of trial and error from the development team.

Unlike development in FileMaker where calculations and scripts are validated as you go, PHP pages are written in a text editor and are only compiled when the page is accessed via a web browser. It's therefore not apparent whether the PHP page you've developed will work correctly until the page is loaded into the web browser. When errors do occur accessing the PHP page, the FileMaker API returns an error code which can be checked against the list of known FileMaker error codes.

Provided below is a selection of error messages we encountered during the PHP development process and the root cause discovered. As you'll see from these examples, the error messages returned don't always provide a clear pointer to the underlying cause.

Error 5: Command is invalid (for example, a Set Field script step does not have a calculation specified)
The actual cause of this problem (on this occasion) was the incorrect specification of the layout name.

Error 201: Field cannot be modified
Sometimes calculation fields are inadvertently included on forms that are used to create or edit information in the database. The error message above is returned when attempting to update a field that is a calculation field as it cannot be updated manually.

Error 104: Script is missing
While the error code indicates a script is missing the script being called did exist in the database and could be executed manually. Further investigation found that the user account being used to login to the web application (by some users) did not have privilege to run the relevant script.

Insight gained
When troubleshooting issues relating to your FileMaker web applications think in terms of a user accessing the database directly using the FileMaker Pro client software.

1. Account privileges - Does the login account being used have the privilege to perform the required actions on the specified tables?
2. Layout - Has the layout name been spelled correctly? Do you use the right layout? Make sure the user account that is used for this query has the permissions to access this layout.
3. Field - Is the field required included on the layout specified?

If the user can't carry out the required action directly in FileMaker they won't be able to do it via the web.

Indexes Not Working?

This particular problem arose in a FileMaker v9 solution that we inherited from another developer. The system had been in operation for several years, it was operating as expected and the client was happy. All seemed good in the world.

Suddenly and without warning, functions that had been working perfectly stopped performing as expected. The client contacted us and explained that Function X wasn't working. As per Murphy's Law, it was a business critical function that handled inbound enquiries and needed to be fixed ASAP. Due to high staff turnover at this company it was difficult to get a concise description of exactly what the function did so we set about investigating the relevant layouts and scripts. The scripts responsible were overly complicated and used methods more akin to a v6 solution but the function has been working correctly and we were assured nobody had modified the relevant Scripts.

After much debugging I tracked the problem to a series of "Go To Related Record" (GTRR) script steps that were failing. I checked the relevant Relationships and everything looked good. They were based on a multi-line key but were logically correct and should have displayed the correct records. Instead, the GTRR step was resulting in a found set of zero records, causing the rest of the process to fail. After much head scratching I performed a Recover of the files - still no change.

After further investigation I checked the index values for one of the key fields used in the relationship. It returned a blank, the index was empty. I couldn't even perform manual searches on the field! I checked the field definitions and Indexing was turned on so it was not un-indexed by design, certainly the relationships defined for this file required the field to be indexed.

To "rebuild" the indexes for that field I turned indexing off and on again on the relevant Field Options > Storage tab and then performed a "View Index" command on the field. The indexes were re-calculated, finding was restored and the GTRR script step was now performing as expected. The database has since operated without further fault.

Perhaps we should have rolled back to a back-up of the database, prior to this issue occurring however I'm not sure whether it would have made any difference. Certainly the database didn't exhibit any other problems and a Recover of the file found no issues. Just a glitch in the Matrix perhaps?

Insight gained
Even though everything might look as though it should work, the underlying data will always determine the outcome.

Welcome to FileMaker Insights

The purpose of this blog is to provide a source for tips and advice regarding FileMaker Pro. During the course of a normal working day our development team will strike various problems that need to be solved. In some cases we'll ask another member of staff, perform a search online or even consult the Help documentation. Sometimes we can't find an answer and just need to nut it our ourselves!

In some instances the insights we'll post will be trivial, perhaps something you've known for years. Others will be a little more complicated, things we haven't seen referenced elsewhere. Either way, we hope you'll find a few gems that will save you time.

Welcome aboard!