Sub titled:
I never really cared about the first record in the database anyway :-)

Thanks to:

No blogs where harmed in the making of this stream of (semi) random ideas. However a lot were read. Thanks to:
Kevin Franks at FileMaker Hacks
The Digital Fusion guys at Weetabix even if spelling their particular favourite cereal is a challenge :-)

These are a bunch of thoughts in some semi random order; I will add to them over time. The idea is to get us some talking points to start the session.

Having seen a lot of FileMaker solutions over the years that fall between optimistic and fatally flawed in terms of error capture I want to discuss what constitutes acceptable, good and best practice in writing code.

So starting from a point of whats worse, sticking Set Error Capture [ON] at the start of all scripts and ignoring errors or just ignoring errors?

How do you update, delete and create records without risk?

Test for record creation to avoid overwriting random records

For related records pass a key, is it essential to test this key exists?

Write scripts so all testing occurs before all database amendments, much easier to back out of

Consider Todd Geist's transactional modal.

Reusable code and GTRR

GTRR demands its own raft of error capture and leads to more code. Is a passing in a primary key and doing a find preferable?

Is a script parameter and a find more robust? It is slower, is it worth it?

Writing one script to perform one function with considered error capture reduces

Triggers nuisance or menace? New window function suppressing triggers. Where do you suppress triggers? A window name is specific to the location a trigger is going to run from (at least where most problematic triggers are called from anyway).

Passing data between functions - Take a bow Fabrice :-)

XML custom functions
  • Self documenting
  • Verbose

SELF, you are your own best friend and everything everyone told you about being selfish is wrong.

Self, any disadvantages? Learn to love it!

FMEA (Failure Mode Effect Analysis or F* Meaningless Engineering Application?)

FMEA is an engineering technique used to prioritise the likelihood and level of risk of a failure mode, its old school engineering from metal bashers but is it applicable here?

As a philosophy or top level approach to working does FMEA help?

Saving yourself from yourself, remember what you Mum said about walking round with your shoe laces undone?

I am also interested in how many people protect their SQL using relatively simple best practices as highlighted here. Overkill? Is an entry in the field comments recording that a given field is used in Execute SQL (or indeed through the PHP API) enough? Given its harder to insulate the PHP API in the same way, why not take a SQL'esque approach to renaming fields and TOs (ie don't).

Fabrice has a custom function that enables you to use an internal FileMaker id instead any object name here. The trickiest part of using this is making sure your SQL remains readable when you use it.

*my session still working on details, any ideas/thoughts let me know - Damian