MonkeybreadSoftware Posted yesterday at 08:09 AM Posted yesterday at 08:09 AM Do you have a FileMaker Server with multiple databases? Do you like to keep track who makes changes? With FileMaker Server 21.1 the Plugin SDK got a new entry point for requesting schema changes. This provides a way for the plugin to be notified about changes to any of the databases on the server. With changes to the schema, we mean changes for these catalogs: custom function custom menu set data source extended privilege field layout privilege set script table table alias theme user account value list There may be more catalogs. Whenever one is these catalogs is touched, you receive a JSON record with the following values: account The account name making the change. basetableid Optionally the table id if a table is modified. catalog One of the catalog names in the list above. file The database file name. id The ID of the item. May be for the list of items and for metadata of the item. user The user name. counter A value added by the plugin to give each record an unique number. time The time stamp when the plugin received the notification. The actual change may have been done a second earlier and the time you query the changes is probably some time later. Start watching On the server in the start script you call SchemaChange.Enable at least once. For example you can call it in the start script of the solution on the server. Once you enable the feature, our plugin starts collecting the JSON records for schema changes. You can of coure run this via PSoS on the server. The callback for the plugin only runs within the server script engine. While you could call the functions on the client, they would simply do nothing. To disable, you can run SchemaChange.Disable in a script. If you like to disable the possibility to disable it, you could use the Plugin.LockFunction function to put a lock on that function. Scheduled script To pick up the changes, we install a script and run it as a scheduled script. In the scheduled script we can query the SchemaChange.Changes function. We get a JSON arrays with all the collected change records. The scheduled script may run every minute or every hour and then process the JSON: # check for pending changes Set Variable [ $changes ; Value: MBS("SchemaChange.Changes") ] # # if we have changes, log them to a table If [ Length ( $changes ) > 0 ] Set Variable [ $r ; Value: MBS("JSON.InsertRecords"; Get(FileName); "SchemaChanges"; $changes) ] # table must have the following fields: account, catalog, file, id, user, basetableid, counter and time End If In our example we have a table to store the records for the modifications. A table with account, catalog, file, id, user, basetableid, counter and time fields. The counter can be a number, but the others are text. You could decide in the script what to do depending on what file or what account is making the change. Like you could send an email when some specific thing is changed or trigger the Save a Copy as XML script step to export the file. Limits The change records tell you what changed on a high level view point. Not much detail is given. Since you only get IDs for items like tables or scripts, you need to collect the information yourself to add a name to the IDs. Either by having a script run for each database file to query the schema and fill in records or by reading in a what is saved as XML from a database. Our plugin with the SchemaChange functions can't know the details. Permissions prevent your script to query the database schema of other files unless you add them as data sources. But you can of course collect this in your own database for your own files. Please try and let us know how well it works.
Recommended Posts