Frequently Asked Questions
What is fmDataGuard?
fmDataGuard is a product for FileMaker Pro and FileMaker Server that is easy to use and easy to configure and performs three main tasks:
First, it creates a complete audit log for all additions, changes, and deletions in any FileMaker Pro table.
Second, it provides the ability to roll-back any single field edit, single record or multiple records to any state in those records’ history.
Third, it provides the ability to roll-forward any record or group of records to reconcile the last known good backup with the current state of the database since that backup. In other words, It updates the backup.
And it does all of these tasks without the need for scripts, multiple shadow fields, or shadow tables. Let me repeat that. No shadow fields that add extensive overhead and maintenance to files. One extra field per table and one extra setting per Table per Privilege Set. That’s all it takes.
What does it mean to Roll Forward a backup?
Simply put, a Roll Forward operation allows a database administrator to update a backup copy of a database to contain Add, Change and Delete activities which were committed after the backup copy was created.
Ordinarily with FileMaker databases this would have to be performed manually by collecting whatever information is available about these post-backup activities.
However, if an Audit Log is available that details these changes, the job is made much easier, but a mechanism, be it manual, or script, must go through the relevant log entries (those which occurred after the last good backup was made) to reapply the entries to the database. Since the entries can involve Add, Change and Delete operations across multiple tables in multiple files, both manual and scripted approaches still present a potentially daunting task.
fmDataGuard provides a means to do this with a single Replace Records operation that will act globally on all selected Audit Log entries to perform the appropriate operations throughout all effected databases.
With this capability, any backup copy of a database or set of databases can be brought up to date within seconds of a crash.
How much does fmDataGuard cost?
See the link for Pricing.
Does it work with older versions of FileMaker Pro and FileMaker Server?
fmDataGuard is not supported for FileMaker Pro and FileMaker Pro Advanced prior to 8.5 and for FileMaker Server and FileMaker Server Advanced prior to 8.0v4.
How can it work without extra fields or scripts?
Presently in FileMaker Pro, to meet Audit Log logging requirements, to provide unified field level tracking, or to provide roll–forward or roll–back of a database creates extensive structural overhead. It requires shadow fields for audit tracking. It may also entail the use of extensive auto–enter calculations, deletion signatures, and scripts. Additionally the reliability of such calculations across multiple files that reference one another on the Relationship Graph is questionable. Also, while FileMaker Server provides excellent backup capability, there is no easy way to update those backups to that last known state of the database. There’s no way to cover the period between the last backup and the crash.
DataGuard solves all these problems without lots of extra fields, calculations, or scripts. It allows for complete logging of creations, edits, and deletions. It can perform roll–backs to reverse errors. It can perform roll–forwards to update backups.
fmDataGuard only requires the addition of a single field (with specific Auto-Enter and Validation options) per table to support Add and Edit activities, and the addition of a Limited Deletion Access Privilege calculation per table, per privilege set, to support Delete activities. No other changes to the database are required. This is a revolutionary addition for FileMaker database management and completely changes the nature of Audit Log and Rollback/Roll Forward support for FileMaker database management.
Where do you store the logs?
The AuditLog is a single FileMaker database table used for at least each database file, and can potentially be a single table used for multiple files. This table is provided by WorldSync in an example file and must contain the specific fields defined in the provided table. This table and can be copied into any desired database or databases using FileMaker Pro Advanced. Each database file to be supported must contain a Table Occurrence to the base AuditLog table of your choosing. By default, the table occurrence must be named “AuditLog,” but this name can be modified if a plug-in function is used to specify to the fmDataGuard plug-in what table occurrence name to use.
To take full advantage of the Roll Forward features provided in fmDataGuard, we recommend that the base table for the AuditLog be maintained, at the least, within a separate database file, and ideally on a machine which is distinct from the machine hosting your own database file(s). The latter, a separate database host, provides the greatest likelihood that in the event of a crash of your primary database server(s) that the AuditLog table will remain intact and thereby allow a means to update your last created full database backup to within minutes or seconds of the primary servers content prior to the crash.
Can fmDataGuard be integrated with an already existing FileMaker Pro solution?
fmDataGuard can be integrated with existing FileMaker Pro database solutions with minimal modification to the database file structure. A single additional field is required per table for capture of Add and Change activities, as well as a limited deletion access privilege per table per Privilege Set. A table called AuditLog is added to one database to hold the logging entries. Additionally, for best results, the AuditLog should be initialized, so that the initial state of the database is reflected in the log.
Does it work on both Macintosh and Windows in a multi-platform office?
Yes. The fmDataGuard works on all platforms supported by FileMaker Pro 8.5 and greater, as well as FileMaker Server 8.0v4 and greater.
What is an Audit Log? Why do I need one?
An Audit Log contains an entry for each time any field throughout a database is modified, including when and who made the change and what the content of the field was both before and after the change. An Audit Log also contains an entry for each record deleted from any table specifying when and who deleted the record.
As for why this is useful, in many environments, either by corporate security policy or by statute or regulation, an authoritative and immutable log is required of all changes to all data elements in one or more tables. Even in environments where this not mandated, keeping such a log using fmDataGuard provides a means to offer much greater protection of the database against crashes and undesirable modifications. fmDataGuard offers both Rollback and Roll Forward functions that can operate on the log to reverse unwanted changes or update a backup to within seconds of a crash.
Is there a demo version I can try?
Yes. Select link to Download Demo
Where can I see the product in action?
Select the link for QuickTime Movie.
Can I get help implementing this in my solution?
For information about an experienced FileMaker developer in your area, send email to Sales.
Does fmDataGuard support multi-file solutions?
Yes. Each solution file requires a Table Occurrence to the AuditLog table, which can reside in any one of the solution files, or ideally, in its own file, and as a Best Practice, on its own FileMaker Server.
Are there any limitations or database requirements which must be met?
There are a small number of limitations as well as requirements that must be met. See the documentation which comes with the demo download for details.
Does fmDataGuard support Instant Web Publishing and other FileMaker External APIs?
Yes. Any mechanism that can modify the data is supported. In order to support External APIs with FileMaker Server, it is necessary to install the plug-in on FileMaker Server.
There is one extra requirements for all External APIs, and one limitation related to Instant Web Publishing.
The extra requirement is that if you keep the AuditLog table in a different file than a particular database being accessed, the Account and Password used by the External API to access the primary file must also exist in the file hosting the AuditLog. This isn’t required from within FileMaker Pro.
The IWP limitation (as of 1v1) is that records can not be deleted by users through an IWP connection. That is, the plug-in will return a False to the Limited deletion condition, hence preventing a user from deleting a record.
Can fmDataGuard be used to provide transaction-level roll back (all or nothing)?
Yes. By setting a Transaction ID flag that gets included in your Audit Log, you can use the Roll Back feature to find these entries and roll each of them back, including Add, Change and Delete operations across multiple files, table and records. Note that unlike selecting Roll Back while working with ODBC/JDBC, your changes will be committed to your datasource as you go, but the Audit Log allows you to reverse the changes that were made after the fact. This will not prevent other users or processes from see the initial changes made in the period before you select to Roll Back.
Can fmDataGuard be used to support other types of logging requirements besides data Add, Change and Delete activity?
Yes. Many regulations or compliance policies require additional types of events to be tracked, such as user login and out, viewing of certain records or running of various reports or batch activities. fmDataGuard provides the ability to write your own types of events to the log as well, simply by calling the function DataGuard_PostCustomEvent (...). Therefore, any of the database design elements that provide a FileMaker Calculation dialog input can be used to post additional entries to the log. Note that New, Edit, Delete, Delete_REQ and tableSchema are reserved event types and should not be use to post custom events.
fmDataGuard is a product for FileMaker Pro and FileMaker Server that is easy to use and easy to configure and performs three main tasks:
First, it creates a complete audit log for all additions, changes, and deletions in any FileMaker Pro table.
Second, it provides the ability to roll-back any single field edit, single record or multiple records to any state in those records’ history.
Third, it provides the ability to roll-forward any record or group of records to reconcile the last known good backup with the current state of the database since that backup. In other words, It updates the backup.
And it does all of these tasks without the need for scripts, multiple shadow fields, or shadow tables. Let me repeat that. No shadow fields that add extensive overhead and maintenance to files. One extra field per table and one extra setting per Table per Privilege Set. That’s all it takes.
What does it mean to Roll Forward a backup?
Simply put, a Roll Forward operation allows a database administrator to update a backup copy of a database to contain Add, Change and Delete activities which were committed after the backup copy was created.
Ordinarily with FileMaker databases this would have to be performed manually by collecting whatever information is available about these post-backup activities.
However, if an Audit Log is available that details these changes, the job is made much easier, but a mechanism, be it manual, or script, must go through the relevant log entries (those which occurred after the last good backup was made) to reapply the entries to the database. Since the entries can involve Add, Change and Delete operations across multiple tables in multiple files, both manual and scripted approaches still present a potentially daunting task.
fmDataGuard provides a means to do this with a single Replace Records operation that will act globally on all selected Audit Log entries to perform the appropriate operations throughout all effected databases.
With this capability, any backup copy of a database or set of databases can be brought up to date within seconds of a crash.
How much does fmDataGuard cost?
See the link for Pricing.
Does it work with older versions of FileMaker Pro and FileMaker Server?
fmDataGuard is not supported for FileMaker Pro and FileMaker Pro Advanced prior to 8.5 and for FileMaker Server and FileMaker Server Advanced prior to 8.0v4.
How can it work without extra fields or scripts?
Presently in FileMaker Pro, to meet Audit Log logging requirements, to provide unified field level tracking, or to provide roll–forward or roll–back of a database creates extensive structural overhead. It requires shadow fields for audit tracking. It may also entail the use of extensive auto–enter calculations, deletion signatures, and scripts. Additionally the reliability of such calculations across multiple files that reference one another on the Relationship Graph is questionable. Also, while FileMaker Server provides excellent backup capability, there is no easy way to update those backups to that last known state of the database. There’s no way to cover the period between the last backup and the crash.
DataGuard solves all these problems without lots of extra fields, calculations, or scripts. It allows for complete logging of creations, edits, and deletions. It can perform roll–backs to reverse errors. It can perform roll–forwards to update backups.
fmDataGuard only requires the addition of a single field (with specific Auto-Enter and Validation options) per table to support Add and Edit activities, and the addition of a Limited Deletion Access Privilege calculation per table, per privilege set, to support Delete activities. No other changes to the database are required. This is a revolutionary addition for FileMaker database management and completely changes the nature of Audit Log and Rollback/Roll Forward support for FileMaker database management.
Where do you store the logs?
The AuditLog is a single FileMaker database table used for at least each database file, and can potentially be a single table used for multiple files. This table is provided by WorldSync in an example file and must contain the specific fields defined in the provided table. This table and can be copied into any desired database or databases using FileMaker Pro Advanced. Each database file to be supported must contain a Table Occurrence to the base AuditLog table of your choosing. By default, the table occurrence must be named “AuditLog,” but this name can be modified if a plug-in function is used to specify to the fmDataGuard plug-in what table occurrence name to use.
To take full advantage of the Roll Forward features provided in fmDataGuard, we recommend that the base table for the AuditLog be maintained, at the least, within a separate database file, and ideally on a machine which is distinct from the machine hosting your own database file(s). The latter, a separate database host, provides the greatest likelihood that in the event of a crash of your primary database server(s) that the AuditLog table will remain intact and thereby allow a means to update your last created full database backup to within minutes or seconds of the primary servers content prior to the crash.
Can fmDataGuard be integrated with an already existing FileMaker Pro solution?
fmDataGuard can be integrated with existing FileMaker Pro database solutions with minimal modification to the database file structure. A single additional field is required per table for capture of Add and Change activities, as well as a limited deletion access privilege per table per Privilege Set. A table called AuditLog is added to one database to hold the logging entries. Additionally, for best results, the AuditLog should be initialized, so that the initial state of the database is reflected in the log.
Does it work on both Macintosh and Windows in a multi-platform office?
Yes. The fmDataGuard works on all platforms supported by FileMaker Pro 8.5 and greater, as well as FileMaker Server 8.0v4 and greater.
What is an Audit Log? Why do I need one?
An Audit Log contains an entry for each time any field throughout a database is modified, including when and who made the change and what the content of the field was both before and after the change. An Audit Log also contains an entry for each record deleted from any table specifying when and who deleted the record.
As for why this is useful, in many environments, either by corporate security policy or by statute or regulation, an authoritative and immutable log is required of all changes to all data elements in one or more tables. Even in environments where this not mandated, keeping such a log using fmDataGuard provides a means to offer much greater protection of the database against crashes and undesirable modifications. fmDataGuard offers both Rollback and Roll Forward functions that can operate on the log to reverse unwanted changes or update a backup to within seconds of a crash.
Is there a demo version I can try?
Yes. Select link to Download Demo
Where can I see the product in action?
Select the link for QuickTime Movie.
Can I get help implementing this in my solution?
For information about an experienced FileMaker developer in your area, send email to Sales.
Does fmDataGuard support multi-file solutions?
Yes. Each solution file requires a Table Occurrence to the AuditLog table, which can reside in any one of the solution files, or ideally, in its own file, and as a Best Practice, on its own FileMaker Server.
Are there any limitations or database requirements which must be met?
There are a small number of limitations as well as requirements that must be met. See the documentation which comes with the demo download for details.
Does fmDataGuard support Instant Web Publishing and other FileMaker External APIs?
Yes. Any mechanism that can modify the data is supported. In order to support External APIs with FileMaker Server, it is necessary to install the plug-in on FileMaker Server.
There is one extra requirements for all External APIs, and one limitation related to Instant Web Publishing.
The extra requirement is that if you keep the AuditLog table in a different file than a particular database being accessed, the Account and Password used by the External API to access the primary file must also exist in the file hosting the AuditLog. This isn’t required from within FileMaker Pro.
The IWP limitation (as of 1v1) is that records can not be deleted by users through an IWP connection. That is, the plug-in will return a False to the Limited deletion condition, hence preventing a user from deleting a record.
Can fmDataGuard be used to provide transaction-level roll back (all or nothing)?
Yes. By setting a Transaction ID flag that gets included in your Audit Log, you can use the Roll Back feature to find these entries and roll each of them back, including Add, Change and Delete operations across multiple files, table and records. Note that unlike selecting Roll Back while working with ODBC/JDBC, your changes will be committed to your datasource as you go, but the Audit Log allows you to reverse the changes that were made after the fact. This will not prevent other users or processes from see the initial changes made in the period before you select to Roll Back.
Can fmDataGuard be used to support other types of logging requirements besides data Add, Change and Delete activity?
Yes. Many regulations or compliance policies require additional types of events to be tracked, such as user login and out, viewing of certain records or running of various reports or batch activities. fmDataGuard provides the ability to write your own types of events to the log as well, simply by calling the function DataGuard_PostCustomEvent (...). Therefore, any of the database design elements that provide a FileMaker Calculation dialog input can be used to post additional entries to the log. Note that New, Edit, Delete, Delete_REQ and tableSchema are reserved event types and should not be use to post custom events.