fmDataGuard Changelog

Back to fmDataGuard

• - fmDataGuard 2.0v3 - 1st April 2010
  
  • Resolved issue with Rollback/Roll Forward of Empty number fields
  • Improved unicode support
  • Modified behavior of StartEdit function to write only one entry per record to the AuditLog_TEMP table instead of one entry per field to improve performance
• + fmDataGuard 2.0v2 - 1st October 2009
  
  • Resolved issue with LogReflect function when referenced from portals whose source table occurrence is not the same as that specified in the log
  • Modified StartEdit function to only update a previously written entry to the temp log if it is more than 5 minutes old
• + fmDataGuard 2.0v1 - 1st July 2009
  
  • Bugs Fixed:
  • Resolved problem with recovering number fields in International environments (where decimal character is a comma)
  • Enabled support for fields whose names include illegal characters such as and, or, &, etc. as well as characters reserved by fmDataGuard (apostrophe and backslash)
  • New Features:
  • DataGuard_StartEdit ( dbName ; tblName ; primaryKeyField ; primaryKeyValue {; fieldPrefixExcludeList {; fieldList {; optionalFieldName ; optionalValue {; mustUpdateSchema }}}} )
  • DataGuard_StartEdit writes the current state of a record to a temporary table (which must be created in advance) as an alternative to requiring the use of the INIT function and the proper maintenance of entries in the log representing the current state of each record. This function should be implemented as a Limited… Record Edit Access Privilege Per Table. Use of this function is optional, but if used, has significant performance and log size reduction enhancements, especially for large databases.
  • NOTE: Use of this new function requires the creation of the table AuditLog_TEMP, which can either be copied and pasted from the fmDG_Example file into your solution files, or you can use the below function call while connected to the database with a Full Access account:
  • DataGuard_UpdateSchema ( Get(FileName) ; “CreateAuditLogTempTable” )
  • Due to above feature (DataGuard_StartEdit) the requirement to perform the INIT function as part of DataGuard deployment has been removed. If StartEdit is being used, use of the INIT function is not recommended, and it is no longer necessary to maintain ANY entries in the log beyond those desired for potential rollback or roll forward usage or other desired log access needs. In other words, a daily replacement and archival of the entire AuditLog file is perfectly acceptable.
  • DataGuard_LogReflect( fieldName {; reflectionType {; tableNameOverride }} )
  • The LogReflect function allows you to easily pull one of three types of information for a named field available on the current layout:
  • “Summary” Retrieves the name and time stamp of the last modifier of the specified field
  • “Before” Retrieves the before value of the last posting for the specified field
  • “After” Retrieves the after value of the last posting for the specified field
  • This function is intended for use with ToolTips in FileMaker, and using the below calculation (or a similar derivative), can be set up as the ToolTip for all fields on a layout in one action by selecting all fields, selecting Format > ToolTip and pasting the below formula:
  • DataGuard_LogReflect ( GetFieldName ( Self ) ; “Summary” ) & “¶” &
  • DataGuard_LogReflect ( GetFieldName ( Self ) ; “Before” )
  • This function returns an error if a field name not on the current layout is specified. This includes fields on the layout for which the current user does not have Read access.
  • DataGuard_Difference ( before ; after )
  • DataGuard_Difference compares two provide text strings and returns a markup showing their difference. This can effectively be used with any text strings, but is provided with the intent to enable display of differences between the Before and After values of a given log entry.
  • DataGuard_GetLastError
  • DataGuard_GetLastError returns the last error code captured by the plugin. It does not clear out after a successful call, but rather retains the last error received until or unless a new error occurs.
  • Replaced error strings with error codes to provide for better international localization capabilities. See “/Documentation/fmDG_ErrorCodes.txt” within product download for error code explanations.
  • Internal Modifications to Post_ functions to provide additional speed optimization, especially for batch activities. 100% speed improvement measured in Example database on record imports.
• + fmDataGuard 1.1v5 - 1st August 2008
  
  • Bugs Fixed:
  • Resolved issue Rolling (forward or back) for tables with spaces in their names.
  • Resolved an issue which prevent the Rolling (forward or back) log entries for Number fields containing invalid (non-numeric) data.
  • New Features:
  • Added support for FileMaker 8.0 databases
• + fmDataGuard 1.1v2 - 1st January 2008
  
  • Resolved a problem with the INIT function, whereby not all records in a table (or found set) would be initialized properly. Specifically, pre-existing log entries for records from other tables but with the same primary key value as a record to be initialized would cause the record to be skipped during logging.
  • Resolved a problem on Power PC computers that resulted in the ‘ character (ASCII character 96) being included at the beginning of each line logged.
  • Removed the Build information from the DataGuard_Version function when the “short” parameter is supplied.
• + fmDataGuard 1.1v1 - 1st November 2007
  
  • Bugs Fixed:
  • Problems with the use of optionalFieldName/Value within the INIT function have been addressed.
  • The presence of backslash character () within data fields led to INIT and PostEdit errors and has been resolved.
  • The presence of the apostrophe character in field names led to INIT and PostEdit errors and has been resolved.
  • The use of primary key fields of type Number within locales that use the comma character as the decimal delimiter lead to INIT and PostEdit errors and has been resolved.
  • Modified Functionality:
  • The following existing functions were modified as specified below. Note that all modifications were added as optional new parameters, so default behavior will remain in effect and existing implementations of these function calls will not be broken.
  • DataGuard_Init – Added two optional Boolean parameters:
  • MustUpdateSchema – (optional) will force the function (on every call) to update the stored list of table schema (fields) for the given table. This is a boolean parameter (“true” or “false”); the default value is “false”. If this parameter is omitted (or included and set to “false”), the table schema will be updated only when an attempt to use the existing field list causes an error or if the function UpdateSchema is explicitly sent for a table.
  • BlockAlert – (optional) will prevent the warning dialog from being presented when the Init call is triggered. This is a boolean parameter (“true” or “false”); the default value is “false”.
  • DataGuard_PostEdit – Added optional Boolean parameter:
  • MustUpdateSchema – (optional) will force the function (on every call) to update the stored list of table schema (fields) for the given table. This is a boolean parameter (“true” or “false”); the default value is “false”. If this parameter is omitted (or included and set to “false”), the table schema will be updated only when an attempt to use the existing field list causes an error or if the function UpdateSchema is explicitly sent for a table.
  • DataGuard_Register – Added optional Boolean parameter:
  • SaveToDisk – causes the plug-in to store the submitted licensing information to disk on the computer that sent the function call, thereby removing the need to recall this function each time the database is opened. Default value is “false”. The license information is saved in the registry on Windows, and in a preference file on the Macintosh. Note that this parameter has to be used at least once on each computer that will use the database.
  • New Features:
  • DataGuard_ExecuteSQL( SQL ; colSepChar ; rowSepChar )
  • This function allows you to send custom SQL queries and updates against your database. This is a generic function call which is not directly related to audit logging in any way. For instance, you could use this function to query a table called Contacts in your solution for a list of all companies within a particular city by sending:
  • DataGuard_ExecuteSQL ( “SELECT CompanyName FROM Contacts WHERE City=’Berkeley’ “; “,” ; “¶”)
  • In the above function call, the comma character is specified as the column separator and the carriage return (r) character is specified as the row separator. Both parameters allow only a single character as a separator.
• + fmDataGuard 1.0v4 - 4th September 2007
  
  • Bugs Fixed:
  • A bug was fixed in the INIT function which effected proper logging when the optional parameter fieldList is used. This bug caused all records but the first in the found set not to be logged correctly.
  • Modified Functionality:
  • A change was made in version 1.0.3 to the way field lists were collected from FileMaker. Previous versions of the plug-in used the FieldNames () design function (internally in the plug-in) to collect field names, but this meant that if a layout existed in a file with the same name as the referenced table occurrence, only the fields on that layout would be logged. In version 1.0.3, an alternative approach was used that lifted this limitation, but which turned out to cause a significant performance drain in solutions with large overall database schemas (large numbers of table occurrences and/or fields). This impacted each PostEdit or INIT call, because the field list was re-collected for each such call.
  • In 1.0.4, we have modified the code to only collect the field list if it has never been derived before for a given table, or to re-collect it if an attempt to log entries for a given table results in a field list error (i.e. field was renamed or deleted). This change removes the performance drain altogether, and will in fact be faster than ever.
  • However, there is one downside to this new approach: If new fields are added to a table, the plug-in will not know they exist and will not log them. To deal with this limitation, a new function call has been added:
  • New Features:
  • DataGuard_UpdateSchema (DbName, TableName) – This call can be sent by the developer when schema changes are made, and will force DataGuard to re-collect the field list in the specified database/table.
• + fmDataGuard 1.0v3 - 21st August 2007
  
  • Bugs Fixed:
  • Licensing issue: The v1 and v2 builds of fmDataGuard are accidentally defaulting to demo mode, which in these builds was configured to expire August 24. The license key you were issued is VALID and will properly register the plug-in with the v3 update. We apologize for any inconvenience this may cause. Note: If you have not already incorporated the DataGuard_Register function into your startup script, you will need to do this in order to activate the plug-in. See the developer guide for more information on this function call.
  • INIT function: Resolved a bug introduced in v2 whereby the DataGuard_Init function would populate the log for each record with data from the first record in the found set, rather than the information for each record.
  • ODBC/JDBC support on FileMaker Server: Resolved a bug introduced in v2 of fmDataGuard that caused connections to hang in some circumstances.
  • New Features:
  • DataGuard_PostView – To better support certain logging mandates, such as HIPAA, we have added an additional function call, DataGuard_PostView, which can be called from a Limited… View Record Access Privilege to cause an entry to be added to the log of event type VIEW each time a user views any record(s). The Example file incorporates this new function as an option, and the developer guide has been updated to explain how to implement this capability.
• + fmDataGuard 1.0v2 - 9th July 2007
  
  • Added support for FileMaker Pro and Server 9
• + fmDataGuard 1.0v1 - 25th June 2007
  
  • Initial Release