When you have a FileMaker solution that you have developed and used over a long time, you are likely to have objects like scripts, table occurrences, value lists, custom functions or layouts, that you don’t use any more. Once in a while you probably want to delete some of them to remove their impact on your solution’s size and performance. But how to be sure you really delete only unused stuff?
We also do this housekeeping from time to time. We use tools like Base Elements, Inspector Pro, or FMPerception to help us to identify the unused stuff. These tools help us to find out which scripts, fields, or layouts are not referenced anywhere. But we are very careful and do not immediately delete them. Instead, we mark them as obsolete, implement some kind of logging of any access to them, and only after they are proven to be unused for long enough, we finally delete them.
You might think this is a paranoid approach but recently it saved us a lot of trouble.
The danger of relying on the mentioned analytical tools is that a script (or another object) can be called or accessed by another technology or in a way that is not identifiable by any tool. You may use Evaluate or ExecuteSQL to access database fields, you may launch scripts from a FileMaker Server script schedule, or via Custom Web Publishing. You may have users switching layouts directly, bypassing your scripted navigation. So it is not only good but sometimes life-saving to be careful before deleting stuff that seems unused.
We have one tip though, how to make it slightly easier to identify those unidentifiable accesses to your solution’s elements. That is defining and strictly applying naming conventions. If you prefix all layouts and scripts accessed via PHP with the “php_” prefix, include “SS” in your server-side script names etc., then you can easily identify the things that might be dangerous to delete, unless you manually verify you’re not using them any more. Then you know you have to search for them in the FileMaker Server Admin Console, or your PHP code, or wherever you have been accessing them from.
Here’s a sample of conventions you can use for this purpose:
