Databuzz releases fmSMS v3 – rewritten for FileMaker Pro 12

Databuzz today announced fmSMS v3, an upgrade to their award winning solution that lets you send and receive SMS/TXT messages from within FileMaker Pro.

fmSMS allows you to send an SMS from FileMaker Pro to almost any mobile phone in the world via one of the supported SMS Gateways, reaching over 860 mobile networks in more than 220 countries. SMS is great means of direct communication with customers, staff, suppliers, and students.

fmSMS v3 was rewritten for FileMaker Pro v12 and includes support for sending messages from FileMaker Go running on the iPad or iPhone. Databuzz will be demonstrating fmSMS v3 at the 2013 FileMaker Developer Conference, to be held in San Diego, California from August 12-15.

What’s New in v3

–        rewritten for FileMaker Pro v12

–        reduced the number of files from 3 to 1

–        now uses the BaseElements plug-in

–        simplified licensing: no limit on the number of FileMaker Pro clients

–        includes a license for FileMaker Server

–        FileMaker Go support for sending messages from an iPad or iPhone*

SMS is perfect for appointment reminders, phone messages, promotions, segmented marketing, school absence alerts, and password confirmations. With SMS you can reduce your costs and play less “telephone tag”.

fmSMS works with multiple SMS Gateway providers internationally and supports the following features**:

–        Send single and bulk SMS messages (messages are typically delivered in under 15 seconds)

–        Send long messages (greater than 160 characters)

–        Works with over 30 SMS Gateway providers internationally

–        Delayed Delivery – send a message now for delivery at a future time

–        Alphanumeric Sender ID

–        Delivery Receipts – track the status of sent messages

–        Message Logging – track the history of all sent messages

–        Message templates – create an unlimited number of pro forma templates

–        2 Way SMS – allow recipients to reply to messages and have them appear in fmSMS

“fmSMS is now easier to integrate into a customer’s existing FileMaker solution than ever,” said Andrew Duncan, Director of Databuzz. “We’ve simplified the licensing and included support for the entire FileMaker platform – you can now send an SMS from FileMaker Pro, FileMaker Go or FileMaker Server.”

Availability, Pricing, and Compatibility

fmSMS v3 is available now from the fmSMS website at http://www.fmsms.com. A 14 day trial version is available for both Macintosh and Windows. Workgroup Licenses start at AUD $495.00. fmSMS requires FileMaker Pro v12.

Upgrade Information

fmSMS v3 is a free upgrade for owners of fmSMS v2.

* FileMaker Go support requires the fmSMS file to be hosted by FileMaker Server

** Not all SMS Gateways support all features of fmSMS. Some features might incur additional charges by your selected SMS Gateway. Some features require hosting by FileMaker Server v12 with Custom Web Publishing using the PHP API and a static IP address. See our website at http://www.fmsms.com for more details.

Media/Customer Contact:

Andrew Duncan

Phone: +61 418 468 103

sales@databuzz.com.au

http://www.fmsms.com

http://www.databuzz.com.au

 

About Databuzz: Databuzz is a long standing member is a member of the FileMaker Business Alliance and has been developing and deploying FileMaker solutions for clients in Australia and internationally since 1999. Our clients are individuals, small-medium businesses, government agencies and multi-national corporations. Databuzz was founded by Andrew Duncan, a Certified FileMaker 12 Developer. In 2010 Andrew presented a session at the annual FileMaker Developer Conference on integrating SMS/TXT Message Integration with FileMaker. For more information please visit our website at http://www.databuzz.com.au.

###

FileMaker is a trademark of FileMaker, Inc., registered in the U.S. and other countries. All other trademarks are the property of their respective owners.

Databuzz to Exhibit at the 2013 FileMaker Developer Conference

FileMaker Inc. have recently released the schedule for the 2013 FileMaker Developer Conference, to be held in San Diego, California from August 12-15. We’re excited to announce that we will be exhibiting at the conference for the first time, showcasing fmSMS v3, our 2 way SMS solution for FileMaker Pro.

 

banner__adhorz-copy

We’ve completely rewritten fmSMS from the ground up for FileMaker Pro v12, with a number of new features including support for FileMaker Go. If you’re coming to the conference please stop by and say hello and we can demonstrate how you can send and receive SMS/TXT messages using FileMaker Pro.

We hope to see as many of you there as possible and look forward to answering your questions about FileMaker and SMS integration.

fmSMS v3 Coming Soon

We’re putting together the final touches to v3 of fmSMS, our two way SMS FileMaker solution that allows you to send and receive SMS/txt messages from your FileMaker database. With the release of FileMaker Pro v12 we decided to take this opportunity to rewrite fmSMS from the ground up, which has meant the v3 release has taken us a bit longer than we expected. Version 1 of fmSMS was originally created with FileMaker Pro v6, and v2 was developed with FileMaker Pro 9, 10 and 11. With the new v12 file format, plugin installation updates and the ExecuteSQL function we decided that it was a good time to go back to the drawing board and start afresh.

We’re also changing the plug-in we use with fmSMS v3 to the free BaseElements plug-in. The BaseElements plug-in already had a number of HTTP functions which we were able to implement quickly, however it was lacking a function that a number of our customers rely: proxy support. We decided to sponsor the development of this function which was included in the recent v2 release of the BaseElements plugin. The function is called as follows:

BE_HTTP_Set_Proxy ( proxy {; port ; username ; password } )

You can supply the proxy server address, along with the three optional parameters for the port number, proxy server username and proxy server password.

We’ve also reduced the number of files down from 3 to a single file. Using the BaseElements plug-in also allows us to remove any licensing restrictions and to include support for FileMaker Server scripts as standard (previously this required customers to purchase an additional plug-in license). We’ve also included support for additional SMS Gateways around the world, including the USA.

We hope to have the new version ready in a few weeks.

FileMaker API for PHP Valuelists and FileMaker Server v12

When working with the FileMaker API for PHP there are a number of functions that are helpful when working with Value Lists. You can use the listValueLists function  to return the names of any value lists associated with the  layout you are referencing, and the getValueLists function to return a multi-level associative array of value lists (i.e. the contents of the value lists on the layout).

I noticed something strange today when working on a FileMaker v12 file hosted with FileMaker Server v12 – using these 2 functions I was seeing value lists that I was sure were not on the layout. After a bit of testing I found the source of the problem – some of the fields which were set to display as a simple “Edit box” had previously been set to display as a “Drop-down list”, and it was the value lists that were previously associated with these fields that were showing. Simply changing the field’s control style from “Drop-down list” to “Edit box” was not enough to remove it from the XML that is returned by the Web Publishing Engine – if you’ve used FileMaker Pro for a while you’ll have encountered this feature where FileMaker can “remember” previous settings for a field on a layout and when you switch it back from “Edit box” to  “Drop-down list” it will remember the value list you had previously selected.

The only way to completely refresh the layout so that “remembered” value lists were not returned by the listValueLists and getValueLists functions was to remove the fields from the layout and manually add them again, ensuring that the control style was set to “Edit box” to start with (this is the default style when adding new fields to a layout).

I quickly checked a v11 solution running under FileMaker Server v11 and I wasn’t able to reproduce this issue, so it looks like a new issue with FileMaker Server v12 only. I’ll report it to FileMaker Inc in case it’s considered a bug, but it’s definitely a change from previous versions of FileMaker Server.

Databuzz now FileMaker 12 Certified

Databuzz is pleased to announce that Andrew Duncan recently passed the FileMaker 12 Certification Exam and is now FileMaker Certified in v8, 9, 10, 11 and 12. FileMaker Certification is your validation that you are hiring an experienced FileMaker professional who has technical knowledge of the complete FileMaker product line and has passed the “Developer Essentials for FileMaker” certification exam.

 

FileMaker 12 Certified Developer

Using ExecuteSQL to Query the Virtual Schema/System Tables

Update for Claris FileMaker Pro 19.4.1 – a new faster query to return base tables is now available in Claris FileMaker Pro 19.4.1 or later. Details can be found in this article.

Update for Claris FileMaker Pro 20 (2023) – FileMaker Pro v20 includes new functions that return information about the base tables instead of all table occurrences making it much easier get a list of base tables. Details can be found in this article.

FileMaker Pro v12 introduced the new ExecuteSQL function, which allows you to perform an SQL query on your FileMaker database. The query can can combine the results of two queries, include dynamic parameters, and lets you specify relationships independent of the relationships graph. It is presently limited to the SELECT statement, which is similar to doing a find using the native FileMaker Pro commands, but is not tied to a particular layout or relationship.

I’m going to discuss one particular use of the ExecuteSQL function in this post: the ability to query 2 “virtual tables” for information about the schema of your FileMaker Pro v12 files. The ability to execute SQL statements has been available via the external plug-in API since FileMaker Pro v7.0v3 was released, and many plug-ins have included this functionality, including MMQuery and the BaseElements plugins. Plug-ins that utilised the SQL functionality have also had the ability to query 2 hidden “virtual tables” for information about the schema of your FileMaker database, including Table Occurrences and Field Names. Now that we have the ability to perform native SQL queries using the ExecuteSQL function in FileMaker Pro v12 we can also query these “virtual tables”.

The 2 “virtual tables” that you can query are FileMaker_Tables and FileMaker_Fields.

FileMaker_Tables returns the following columns:

1. TableName
2. TableID
3. BaseTableName
4. BaseFileName
5. ModCount

Here’s some ExecuteSQL function examples that illustrate how you can query FileMaker_Tables (note that the table occurrences also work with external file references that appear on the graph of the current file. I’m using the Event Management starter solution from FileMaker Pro v12 to illustrate what data is returned as well):

ExecuteSQL ( “SELECT * FROM FileMaker_Tables” ; “” ; “”  )
// Returns TableName, TableID, BaseTableName, BaseFileName, and ModCount  for all Table Occurrences in the current FileMaker Pro v12 file

returns:

Agenda,1065093,Agenda,Event Management,46
Assignees | Contributors,1065094,Contributors,Event Management,115
Contacts,1065098,Contacts,Event Management,140
Contributors,1065097,Contributors,Event Management,115
Events,1065089,Events,Event Management,137
Guests,1065092,Guests,Event Management,62
Guests | Contacts,1065095,Contacts,Event Management,140
Tasks,1065091,Tasks,Event Management,89
Venue Looked Up,1065107,Events,Event Management,137

ExecuteSQL ( “SELECT BaseTableName FROM FileMaker_Tables” ; “” ; “”  )
// Returns list of all underlying Base Tables for all Table Occurrences in the current FileMaker Pro v12 file

returns:

Agenda
Contributors
Contacts
Contributors
Events
Guests
Contacts
Tasks
Events

ExecuteSQL ( “SELECT DISTINCT BaseTableName FROM FileMaker_Tables” ; “” ; “”  )
// Returns a unique list of all underlying Base Tables for all Table Occurrences in the current FileMaker Pro v12 file

returns:

Agenda
Contacts
Contributors
Events
Guests
Tasks

FileMaker_Fields returns the following columns:

1. TableName
2. FieldName
3. FieldType (the SQL data type, not the FileMaker data type)
4. FieldID
5. FieldClass (Normal, Summary, Calculated)
6. FieldReps
7. ModCount

Here’s some ExecuteSQL function examples that illustrate how you can query FileMaker_Fields (once again using the Event Management starter solution from FileMaker Pro v12 to illustrate what data is returned):

ExecuteSQL ( “SELECT * FROM FileMaker_Fields” ; “” ; “”  )
// Returns TableName, FieldName, FieldType, FieldID, FieldClass, FieldReps and ModCount  for all Table Occurrences in the current FileMaker Pro v12 file

returns:

Agenda,EVENT ID MATCH FIELD,decimal,2,Normal,1,4
Agenda,Agenda Item,varchar,3,Normal,1,2
Agenda,Date,date,4,Normal,1,9
Agenda,Explanation,varchar,5,Normal,1,5
Agenda,Time,time,6,Normal,1,7
Agenda,Time Frame Order,decimal,8,Calculated,1,16
Agenda,Time Frame,varchar,9,Calculated,1,12
Assignees | Contributors,EVENT ID MATCH FIELD,decimal,1,Normal,1,5
Assignees | Contributors,Email,varchar,2,Normal,1,19
Assignees | Contributors,Phone,varchar,3,Normal,1,10
Assignees | Contributors,Contributor | MATCH FIELD,varchar,4,Normal,1,26
Assignees | Contributors,Role,varchar,5,Normal,1,1
Assignees | Contributors,Assignment,varchar,13,Calculated,1,19
Assignees | Contributors,Photo | Container,binary,14,Normal,1,5
Assignees | Contributors,Assignment Status,decimal,16,Calculated,1,3
Assignees | Contributors,Photo Placeholder,varchar,18,Calculated,1,3
Contacts,First,varchar,2,Normal,1,2
Contacts,Last,varchar,3,Normal,1,2
Contacts,Contacts | MATCH FIELD,varchar,4,Calculated,1,26
Contacts,Job Title,varchar,5,Normal,1,2
Contacts,Company,varchar,6,Normal,1,5
Contacts,Work Email,varchar,7,Normal,1,4
Contacts,Work Phone,varchar,8,Normal,1,2
Contacts,Mobile Phone,varchar,9,Normal,1,2
Contacts,Fax,varchar,10,Normal,1,1
Contacts,Website,varchar,11,Normal,1,1
Contacts,Address 1,varchar,12,Normal,1,3
Contacts,City,varchar,13,Normal,1,3
Contacts,State,varchar,14,Normal,1,3
Contacts,Postal Code,varchar,15,Normal,1,3
Contacts,Country,varchar,16,Normal,1,3
Contacts,Address 2,varchar,17,Normal,1,4
Contacts,CONTACT ID MATCH FIELD,decimal,33,Normal,1,7
Contacts,Initial,varchar,34,Calculated,1,32
Contacts,Sort Selection,global varchar,39,Normal,1,4
Contacts,Sort List Key,varchar,40,Calculated,1,4
Contacts,Photo | Container,binary,41,Normal,1,4
Contacts,Title,varchar,42,Normal,1,1
Contacts,Home Phone,varchar,43,Normal,1,1
Contacts,Home Email,varchar,44,Normal,1,5
Contacts,Notes,varchar,46,Normal,1,2
Contacts,Address Short,varchar,48,Calculated,1,8
Contacts,File Name Placeholder,varchar,49,Calculated,1,4
Contacts,Result Label Plural,varchar,50,Calculated,1,2
Contributors,EVENT ID MATCH FIELD,decimal,1,Normal,1,5
Contributors,Email,varchar,2,Normal,1,19
Contributors,Phone,varchar,3,Normal,1,10
Contributors,Contributor | MATCH FIELD,varchar,4,Normal,1,26
Contributors,Role,varchar,5,Normal,1,1
Contributors,Assignment,varchar,13,Calculated,1,19
Contributors,Photo | Container,binary,14,Normal,1,5
Contributors,Assignment Status,decimal,16,Calculated,1,3
Contributors,Photo Placeholder,varchar,18,Calculated,1,3
Events,EVENT ID MATCH FIELD,decimal,1,Normal,1,11
Events,Event,varchar,2,Normal,1,10
Events,Date,date,3,Normal,1,2
etc . . .

ExecuteSQL ( “SELECT * FROM FileMaker_Fields WHERE TableName=’Tasks'” ; “” ; “”  )
// Returns TableName, FieldName, FieldType, FieldID, FieldClass, FieldReps and ModCount  for the “Tasks” table occurrence in the current FileMaker Pro v12 file

returns:

Tasks,EVENT ID MATCH FIELD,decimal,2,Normal,1,5
Tasks,Due Date,date,5,Normal,1,3
Tasks,Task,varchar,6,Normal,1,11
Tasks,Status,decimal,7,Calculated,1,21
Tasks,Assignee | MATCH FIELD,varchar,11,Normal,1,4
Tasks,Status Sort Order,decimal,12,Calculated,1,32
Tasks,Completed,varchar,14,Normal,1,2
Tasks,To Do,decimal,17,Calculated,1,5
Tasks,Overdue,decimal,18,Calculated,1,6
Tasks,Event,varchar,20,Calculated,1,1

ExecuteSQL ( “SELECT FieldName FROM FileMaker_Fields WHERE TableName=’Tasks'” ; “” ; “”  )
// Returns a list of FieldNames   for the “Tasks” table occurrence in the current FileMaker Pro v12 file.The list of field names is in field creation order

returns:

EVENT ID MATCH FIELD
Due Date
Task
Status
Assignee | MATCH FIELD
Status Sort Order
Completed
To Do
Overdue
Event

ExecuteSQL ( “SELECT FieldName FROM FileMaker_Fields WHERE TableName=’Tasks’ ORDER BY FieldName” ; “” ; “”  )
// Returns a sorted list of FieldNames for the “Tasks” table occurrence in the current FileMaker Pro v12 file

returns:

Assignee | MATCH FIELD
Completed
Due Date
EVENT ID MATCH FIELD
Event
Overdue
Status
Status Sort Order
Task
To Do

ExecuteSQL ( “SELECT FieldName FROM FileMaker_Fields WHERE TableName='” & Get ( LayoutTableName ) & “‘ ORDER BY FieldName” ; “” ; “”  )
// Returns a sorted list of FieldNames for the table occurrence of the current layout in the current FileMaker Pro v12 file. I’m on the “Events” layout in this example

returns:

Address
Agenda Item Label Plural
Agenda Item Number | All
Agenda Item Number | Current
City
Contributor Number | All
Contributor Number | Assigned
Country
Date
Description
EVENT ID MATCH FIELD
Email
Event
Guest Label Plural
Guest Number | All
Guest Number | Attending
Layout Selector
Notes
Phone
Postal Code
QuickFind | iOS
Result Label Plural
Sort List Key
Sort Selection
State
Task Label Plural
Task Number | All
Task Number | To Do
Time Frame
Time Frame | Sort Order
Type
Venue

There’s very little official documentation about these virtual tables that I could find – if I’ve made any errors please let me know and I’ll update this post. I’ve created a couple of custom functions for 2 of the queries that I use the most:

ListBaseTables
ListFieldsFromTable

FileMaker’s internal SQL and System Formats

I’ve been using the ability to execute SQL statements via a FileMaker Pro plug-in more and more lately (see An Approach to FileMaker Server-Side Script Debugging for an example of this) and recently encountered one issue that might arise when working with files created with different system formats to those on your computer. It’s important to note that FileMaker Pro uses your computer’s system formats to determine how dates, times, and numbers display and sort when you first created a new file.

I was working with a file that I didn’t even realise was created with different system formats as the developer of the file had set the File Options to “Always use current system settings” which tells FileMaker to use the current system settings for data entry of numbers, dates, and times instead of those saved with the file when it was first created or cloned:

The startup/OnOpen script for the file was also using the Set Use System Formats script step and setting this to [On] which also instructs FileMaker Pro to use the current system formats. It wasn’t until I started using the BaseElements plug-in to enter the current timestamp along with some additional text into a text field that I noticed something was amiss. Instead of inserting a timestamp for my system settings (Australian) which would appear as:

9/11/2011 3:49:07 PM

I was getting this instead:

09.11.2011 15:49:20 Uhr

I did some tests and whenever I evaluated the Get ( CurrentTimeStamp ) function I would get a correctly formatted timestamp for my region (e.g 21/11/2011 3:51:20 PM ) but as soon as I used this in an SQL statement or converted it to a text data type I would lose the system settings and get the original settings that were saved with the file when it was first created (German in this case). This appears to happen anytime you need to convert dates, times etc into a text data type via the calculation engine (not specifically related to using a plug-in), which is what I’m doing with the internal SQL feature and the BaseElements plug-in. For example my plug-in calculation looked liked this:

BE_FileMakerSQL ("
INSERT INTO ServerLog(Description)
VALUES('Logging Commenced at " &  Get ( CurrentTimeStamp ) & "'" & ")")

The only solution that I’m aware of is to create a clone of the file and then open it on a computer with the required system formats. It will then use the local system formats and you will get the same results when converting date and time values to a string.

fmSMS wins Clickatell Personalized Priority Messaging Award

We’re very happy to report that fmSMS, our solution that lets you send and receive SMS messages with FileMaker, has just been announced the winner of the 2011 Clickatell Personalized Priority Messaging Award in the Application Developers Category.



You can read the full announcement here:

http://www.marketwire.com/press-release/Clickatell-Announces-Personalized-Priority-Messaging-Award-Winners-1577896.htm

The full list of winners is at:

http://www.clickatell.com/ppmawards/winners_2011.php

We’ll post a photo of the award when we receive it.

An Approach to FileMaker Server-Side Script Debugging

The ability to schedule the execution of FileMaker Scripts – that is scripts created in ScriptMaker/Manage Scripts using FileMaker Pro/FileMaker Pro Advanced client application – under FileMaker Server was one of the sleeper features when it was first introduced in FileMaker Server v9 in July, 2007. It didn’t even rate a mention in the original press release but it’s become a very important tool in my developer bag ever since. Some examples of how I’m using FileMaker Server Side scripts include:

– one client requires a .xml file to be downloaded each day from a URL and imported into a file that then conditionally updates and creates new records in related tables and logs the execution

– we use server side scripts with our fmSMS solution to enable our clients to have the sending of the SMS messages performed by FileMaker Server instead of the client application. For bulk operations (e.g. sending several hundred or more messages at the one time) or for scheduling messages to be sent in the future this enables a user to offload the heavy lifting to the server which can typically perform the scripts faster and without tying up the user’s computer waiting for the script to run

– another client send and receives emails from a FileMaker database. Sending bulk emails previously would take almost 8 hours for their mailing list and require a dedicated computer to handle this that couldn’t be used for the duration of the script.

– we update account balances overnight for another client so that all searches can be performed on stored – and therefore indexed – number fields instead of unstored calculation fields, which can result in a find operation taking seconds vs minutes for large data sets.

FileMaker Server Side Scripts – Before You Begin

There are several important caveats that you need to know before you dive head first into setting up your FileMaker Server Side scripts:

– not all Script steps are supported. Only “Server” compatible script steps are supported. You can view the list of server compatible script steps by changing the Show Comptability popup menu in the bottom left hand corner the script window when editing a script:

All script steps that are NOT server compatible will then be greyed out, leaving you with the list of compatible script steps:

If you’re hoping to offload the generation of PDF invoices which are then emailed to a contact then you’re out of luck as far as native FileMaker script steps are concerned. You can use the Send Email via STMP Server step but the Save Records As PDF step is not available – hopefully this will be supported in a future version of FileMaker Server.

– some Script steps are only compatible when certain options are selected. For  example the Send Mail step is only compatible when used with the send via Server option (not client):

Any supported script step that has the option of presenting a dialog box to the user is only compatible when the dialog is not displayed – you’ll need to select the “Perform without dialog” option in this case. Examples of this include Sort Records, Commit Records and Delete Record.

– the Allow User Abort script step determines what happens when a server side script encounters an unsupported script step. From the FileMaker Server v11 Help:

  • If the Allow User Abort script step option is enabled (On), unsupported script steps will stop the script from continuing.
  • If the Allow User Abort script step option is disabled (Off), unsupported script steps are skipped over and the script continues to execute.
  • If this script step is not included, scripts are executed as if the feature is enabled, so unsupported script steps will stop scripts.

– A server-side FileMaker script that is running on one FileMaker server cannot open a database that is hosted on a different FileMaker server.

– Server-side FileMaker scripts run in separate sessions on the Database Server. Each session has its own copy of global fields and variables.

– FileMaker Server can also reference FileMaker plug-ins (see the FileMaker Server v11 Help for details on how to install and enable plug-ins under FileMaker Server)

– there is no script debugger!

Server Side Script Logging

The lack of a script debugger is the focus of the rest of this post. FileMaker Pro Advanced provides a number of tools to assist developers in debugging scripts, including the Script Debugger and the Data Viewer. Both of these tools make life easy for the FileMaker developer to see what is happening at each step of the script and the current values in fields and variables that the script is referencing. However when it comes to debugging scripts under FileMaker Server you’re essentially on your own and need to roll your own solution – remember that there is no interface on FileMaker Server to show you the progress of each script and set breakpoints or access the Data Viewer. The FileMaker Server Log Viewer shows some information AFTER the script has executed which can help but it is very limited. The list of Schedules in the Admin Console also shows when the schedule was last completed and when it’s due to run next.

Some of my server-side scripts have hundreds of steps – when things go wrong or you don’t get the result you expected (or nothing appears to happen) you’re not sure where to start. I needed a solution that was as dynamic as possible and would involve the minimal amount of additional schema changes and let me insert the equivalent of breakpoints at any point in the script to capture information about the current state. My solution to this was to create a built-in log table that I can populate as I go without having to change contexts (i.e. no switching to a new layout based on the log table occurrence to create records). This can be done quite easily using the Magic Key/Pivot technique but I wanted a solution that didn’t require any new relationships and required the least amount of additional script steps so I turned to FileMaker’s internal SQL feature that is currently only exposed through the use of an external plug-in.

This approach does require a plug-in – there are several free and paid ones to choose from – but for me it’s the neatest way to adding logging features to a server side script. Once you’ve installed and enabled the plug-in under FileMaker Server you can easily add some logging features to your database to help you debug a server-side script process. Here’s my approach to server-side script debugging/logging:

– in the database that contains the script I copy/paste in a new table: ServerLog. This table has a handful of fields and FileMaker Pro will then create a single table occurrence and layout for you automatically (you can make the layout visible only in Layout mode). Do NOT rename or delete the table occurrence!

– install and enable the plug-in that can perform the internal SQL operations for you: see the list of plug-ins at the end of this article that I’ve used recently. I currently use the free BaseElements Plugin(thanks Goya!) and my example file uses the BaseElements plug-in to demonstrate my approach. Instructions for installing and enabling plug-ins under FileMaker Server can be found in the FileMaker Server v11 Help under “Managing plug-ins”.

– if your database has an OnFirstWindowOpen/startup script or a OnLastWindowClose/close script (as set under the File Options for the file) you might need to modify these depending on your requirements. These scripts will be performed by the server-side script and depending on their compatibility with server side steps and the use of the Allow User Abort script step that may create unexpected results. I typically bypass the startup and close scripts when performed under FileMaker Server by adding the following steps to the top of the script:

If [ PatternCount ( Get (ApplicationVersion); "server") ]
    Exit Script [  ]
Else
... continue with script as normal

– I set a local variable at the top of the actual server-side script that I wish to debug to allow me to enable or disable the logging on the fly:

Set Variable [ $EnableLoggingSQL; Value:1 ]

– as I’m using a plug-in I need to test that the plug-in is installed (and possibly registered and also the correct minimum version if required)

– I first delete all previous entries in my ServerLog table as I’m only interested in the log files for the current script execution (you can bypass this if you wish to keep a history). Here’s where the power of FileMaker’s internal SQL engine kicks in – I don’t need to change layouts, show all records, then delete them and return to the orignal layout. I can simply make one function call as the calculation value for a Set Variable script step (N.B. all examples in this post are using the BaseElements plug-in):

Set Variable [ $serverLogSQL; Case ( $EnableLoggingSQL ; BE_FileMakerSQL ("DELETE FROM ServerLog") ) ]

The function call and syntax will depend on the plug-in you use but the SQL statement will generally be similar. Here the use of  “DELETE FROM ServerLog” deletes all records in the ServerLog table. Note that I’m wrapping the plug-in call within the Case function which checks whether logging has been enabled (the $serverLogSQL variable is set to either 1 or 0 at the top of the script) – if logging is enabled the plug-in function will be evaluated, otherwise it will be ignored. Be careful when using the SQL Delete command as, unlike FileMaker Pro, you WON’T get a dialog box confirming that you wish to delete the records.

– Adding a single Set Variable script step is usually the maximum that you need to add if you wish to capture and log information about the current state (e.g. by calling one of FileMaker’s functions) or by checking the result of the last script step or retrieving the current value of a variable or field. For example the following Set Variable steps will return information using FileMaker Get Functions:

Set Variable [ $serverLogSQL; Case ( $EnableLoggingSQL ; BE_FileMakerSQL ("INSERT INTO ServerLog(Description) VALUES('Logging Commenced at " &  Get ( CurrentTimeStamp ) & "'" & ")"))]
Set Variable [ $serverLogSQL; Case ( $EnableLoggingSQL ; BE_FileMakerSQL ("INSERT INTO ServerLog(Description) VALUES('Get (AccountName) result " &  Get ( AccountName ) & "'" & ")") )]

– you don’t always necessarily need to add a Set Variable step to create a log entry: anywhere you can access FileMaker’s calculation dialog you can create a log entry. For example you can add a log entry when the Exit Script step is performed as long as you specify a calculation result. I usually decide where in my script I’m going to start debugging and add one or more Set Variable steps at the appropriate places then perform the script manually using the FileMaker Server Admin Console:

 

– when setting up the new Schedule for the server side script in the FileMaker Sever Admin Console you’ll need to specify the Account Name and Password to use when performing the script. Make sure the Account Name and Password has sufficient privileges to perform the required steps. I generally create a new Account for server side scripts with the appropriate privileges. It’s also worth nothing that Get(AccountName) returns the account name that the script was run under and Get(UserName) returns the schedule name.

When it comes to setting up the frequency for the Schedule that you create in the FileMaker Server Admin Console you might be surprised that there’s no option that lets you create a script that runs every x minutes all the time. The limitation is that the start time and end time of a schedule must fall within the same day – there’s no option to tell it to run every day every 5 minutes for example. You can work around this by creating a schedule that starts say at 12:01AM and finishes at 11:59pm if you require a script that runs constantly every 5 minutes.

Whilst debugging I strongly recommend enabling the email notification to get as much information as possible about the execution of the server side script. You can also use the Log Viewer in the FileMaker Server Admin Console to view relevant log entries – these are often helpful as they pinpoint the script step that caused an error. It’s also worth noting that not all errors are actual errors. For example if you’re script involves a Find operation that results in no records found (error #401) this will be captured but might be completely expected. Also if your FileMaker script involves a Loop that uses the  Go to Record/Request/Page [ Next ] step you’ll get an error when it gets to the last record (error #101 – once again this would be expected). You can use the following step immediately above the Go to Record/Request/Page [ Next ] step to bypass this:

Exit Loop If [ Get (FoundCount ) = Get (RecordNumber ) ]

The FileMaker Server Admin Console also allows you to specify some Script Options. You can select Abort schedule if time limit reached or server stopped in the Schedule assistant to abort the FileMaker script schedule if the script takes longer to run than the specified Time limit, or if the Database Server stops:

I’ve created an example file that you can download and pull apart (you’ll need to also download the BaseElements plugin (link below) and install and enable this on FileMaker Server):  ServerLogging.fp7

Here’s a list of the plug-ins I’ve used with my server-side debugging approach:

BaseElements Plugin

SQL Runner

MMQuery

 

Additional Resources:

FileMaker’s Internal SQL Engine, part 1 

Server Side Imports and Exports

FileMaker Server 11 Help

FileMaker Server Event Log Messages

Creating .zip archives from FileMaker using AppleScript

All FileMaker developers have their own habits about how they develop, what tools they prefer to use and how they setup their working folders and backups. I develop on locally stored files as well as files hosted by FileMaker Server (I do a lot of FileMaker Custom Web publishing work using the FileMaker PHP API which requires the files to be hosted by FileMaker Server). I’ve traditionally developed using locally stored files except for my CWP/PHP work and have used a companion database for each new project that I start that I use to create compressed timestamped backup archives of my master database file/s and any associated php files.

I use a mix of backup plans to keep known good copies of my files locally as well as off-site (this post doesn’t go into the details of what constitutes a comprehensive backup plan). Whilst I’m developing I like to close my files periodically (usually every 20-30 minutes or after a major chunk of work has been done) and make a quick .zip of the files before proceeding. I’ve been working this way for so long now (over 10 years from memory) that it’s become a habit for me. I’ve also learnt the hard way too – there’s nothing worse than having to re-do a major chunk of work because FileMaker crashes, you accidentally click cancel instead of OK, there’s a blackout and you haven’t got a UPS etc etc. I go to great effort to ensure that files I’m working on for my clients have never crashed before they are deployed into production – if FileMaker Pro Advanced did crash whilst I had any client files open I simply trash them and revert to the previous backup I had made. I also like to confirm that the files that I’m about to copy into a .zip archive are in fact closed first.

I use a simple FileMaker database that I duplicate for every new project that I start – the link to download this is below. It’s Mac only as it uses AppleScript – I do 99% of my development on the Mac platform so this makes sense for me. It has 4 fields that I use to store the locations to:

  1. the source folder containing the master database file/s that I’m working on (always stored on my local hard disk)
  2. the destination folder where I wish to save a backup .zip archive of these into (usually on an external hard disk)
  3. the source folder containing the master PHP files that are associated with the current project (if applicable)
  4. the destination folder where I wish to save a backup .zip archive of these PHP files (usually on an external hard disk)

Getting the Path to the Source and Destination Folders

Before I can create the .zip archive I first need to populate these fields with the path to my selected source and destination folders. To do this I perform a very simple AppleScript:
set theFolder to choose folder
copy POSIX path of theFolder as text to cell "zResult_g" of current record
which prompts the user to select a folder using the familiar Mac OS X dialog box:
If I haven’t already created the folder in the appropriate location I can click the New Folder button to create it as I go, all from within the same dialog. Assuming I click the Choose button and not the Cancel button the path to the selected folder will be returned to the FileMaker via the 2nd line of the AppleScript which copies this to the zResult_g field (N.B. all the fields in this example are global fields and there is only one table so I don’t need to specify which table or record for AppleScript to reference). Note that I’m instructing AppleScript to return the POSIX  path to the selected folder – this is important as the POSIX path is required by the shell script to create the .zip archive in the 2nd AppleScript. The POSIX path should look something like this:
/Users/andrew/Documents/FileMaker/Projects/Example Project/
If I didn’t specify the POSIX path it would return the AppleScript path which looks something like this:
Macintosh HD:Users:andrew:Documents:FileMaker:Projects:Example Project:
The syntax for returning the AppleScript path would be:
copy theFolder as text to cell "zResult_g" of current record
Once I’ve selected the path to the source and destination folders I’m using some additional FileMaker calculation fields to retrieve the path to the parent folder of the selected folder and also the name of the selected folder. I need to refer to these folders when running the shell script that makes the .zip archive as I want it to run from the location of the parent folder and tell it the name of the folder to archive (this involves performing the change directory command later on to switch to the location of the parent folder). This is not strictly necessary but results in a much neater .zip archive when expanded that doesn’t include all of the folder paths to the source folder – this is because by default AppleScript is running the shell script from the root directory. I could also generate these paths within AppleScript without too much effort but I’m a novice when it comes to AppleScript and can do this quite easily in FileMaker Pro as well.
The field ProjectDatabaseFolderParent_c does a simple calculation to get the path to the parent folder of the selected folder (still using the POSIX format):
/Users/andrew/Documents/FileMaker/Projects
and the field ProjectDatabaseFolder_c calculates the name of the selected folder:
Example Project

Creating the .zip archive/backup

There are 2 buttons to create the .zip backup for both the FileMaker databases and the PHP files. Both buttons perform the same script but pass in a different parameter to the script. The FileMaker script that is attached to these buttons use native FileMaker script steps to check for any mandatory requirements (e.g. that I’ve selected a source and destination folder, that there are no other FileMaker files open etc) and then perform an AppleScript that creates the .zip archive. The AppleScript executes a few processes in order as follows:
set tableName to "Backup Template"
set the item_path to get data cell "ProjectDatabaseFolder_c" of table tableName
set the backupFolder to get data cell "BackupProjectDatabaseFolderPath" of table tableName
set the parentFolder to get data cell "ProjectDatabaseFolderParent_c" of table tableName
set the startFolder to the quoted form of (parentFolder as text)

This section retrieves the values from the fields in the Backup Template.fp7 file that the AppleScript needs to reference when running the shell script. Note that the references to the FileMaker fields are hardcoded in strings – if you rename any of these fields you will need to update the AppleScript or it will break (as far as I know you can’t reference FileMaker $ variables from within an AppleScript but I would love to be proved wrong here). The next step is to generate the timestamped filename that will be used when creating the .zip archive:

set aDate to (current date)
set fDate to formatDate(aDate) & ".zip"
on formatDate(aDate)
set {yr, mo, dy, hr, mn, sc} to ¬
{year, month, day, hours, minutes, seconds} of aDate
return ("" & addLeadingZero(dy) & ¬
addLeadingZero(mo as integer) & yr & " " & ¬
addLeadingZero(hr) & ¬
addLeadingZero(mn) & addLeadingZero(sc))
end formatDate
on addLeadingZero(n)
return text -2 thru -1 of ("00" & n)
end addLeadingZero

Essentially all I’m doing here is getting the current timestamp then extracting the various date and time components in the format which I require. This will result in a filename like “10102011 150304.zip” (I’m using the Australian preferred DDMMYYYY HHMMSS format to generate the text timestamp string but you can re-order this any way you like). AppleScript, like FileMaker, has it’s own rules about data types and how date and times are formatted so I have to add any leading zeros where required etc.

Now I’m ready to create the .zip archive by calling a shell script:

tell application "Finder"
set the sourceFolder to the quoted form of (item_path as text)
set zipFile to fDate as text
set the zipFolder to the quoted form of ((backupFolder & zipFile) as text)
set shellscript to ("cd " & startFolder & "; /usr/bin/zip -r " & zipFolder & " " & sourceFolder)
do shell script shellscript
end tell

Note that I’m first changing directories in the shell script to the parent folder before I generate the .zip archive using the “cd” command. As I’m calling more than 1 command in my shell script I’m using the semi-colon character to separate these.

Finally I’m passing the result back to a global utility field in the FileMaker table:

copy result as text to cell "zResult_g" of current record

It returns the the result of the AppleScript which shows the file/s that were compressed and how much compression was achieved for each:

adding: Databases Test/ (stored 0%)
adding: Databases Test/FileMaker Project A.fp7 (deflated 90%)
adding: Databases Test/FileMaker Project B.fp7 (deflated 64%)

I’ve included the zResult_g field on the main layout as I can use that as a quick visual reference as to how the AppleScript performed. From my quick testing there are some Objects in the FileMaker AppleScript dictionary that do require the field to be on the layout – I haven’t found a definitive list of these yet and haven’t completed the results of my testing of these. If you were to remove the zResult_g field it will break the last line of the AppleScript.

The actual AppleScripts were cobbled together from various examples that I found on the Internet as well as making use of the FileMaker Pro Apple Events reference database. I’m very much a beginner when it comes to AppleScript so many of you can probably optimise the actual AppleScripts – for example I’m not bothering to do any error trapping in the AppleScript.

You can download a copy of my backup tool here: BackupTemplate.fp7

If you have any comments and suggestions about how this tool can be improved please leave a comment below and I’ll post an updated version of with any changes. I’m planning on updating this in the future to do some error handling in the actual AppleScript as well as some other tests, such as ensuring the destination folder isn’t the same as the source folder etc. This database was created and tested under Mac OS X 10.6.8 – your milage may vary on other versions of Mac OS X.

Here are some references that you might also find useful if you wish to modify this tool yourself or learn more about AppleScript and FileMaker:

Introduction to AppleScript Language Guide

AppleScript Error Codes

Keeping good backups – a simple snapshot tool (Goya)

A Simple Backup Script (filemakerhacks)

Create Contacts in the OS X Address Book (Mark Banks)

AppleScript Essentials – Introduction to Scripting FileMaker Pro (mactech)

Apple Events Reference database (FileMaker Inc)

Applescript bold & fearless PauseOnError video by Bruce Robertson

AppleScript and POSIX paths