"Definitions 3" Tab - Basic Settings
Log "Recover" operations: One of the features of the auditing system is that you may recover (undelete) any single record of any file from the audit file. You may define a secondary audit file to store the information about these recovered records, including which record, who and when was retrieved.
In the main app, or for a multi-dll system in your data dll app and in the app where you will use the control template (these can be the same app), you should activate this option if you want to use the recover recording system.
"Definitions 3" Tab - Advanced Settings
Enable SQL for ODBC Autonumber Insert: In some SQL systems like MySQL, when you use an autonumber key, the recovered record will always take a new number, unless you recover it using SQL syntax. You may then activate the "Enable SQL for ODBC Autonumber insert" option in this control to change the insert syntax from Clarion code (ADD...) to SQL code (INSERT INTO...), when the file is SQL (Currently ODBC and Pervasive SQL files are supported).
Generate all empty fields as NULL: If your fields are Nullable, you may also check the "Generate empty fields as NULL" option. This will generate a NULL clause instead of '' or 0 to fill the fields. Keep in mind that if you have any no nullable fields, this option may cause an SQL backend error.
Then, you may change the "Recover File variables".
| • | Audit Recover File: First, in "Audit Recover File", you have to specify the name for your Audit recover file. This is the file where the recover operations are going to be logged. In our example DCT is the file AuditRec. |
| • | Identification: Is the field that contains the auto numbering for the information about the recovered audit records. Normally it would be a LONG or ULONG type of field. |
| • | Id. Key: Among the Audit Recover file keys, you have to specify which one is the one that carries the auto numbering field. Normally it would have one single component, the identification field. |
| • | Link to audit: Is the field that contains the link for the audit records, so the recovered information could be show in a browse box. This field has to be identical to the identification field from the audit file. |
| • | User: This field will contain the identification of the user that recovers the deleted record. |
| • | Date: This will be the date when the record was recovered. |
| • | Time: This will contain the time when the record was recovered. |
| • | Was Forced?: When you recover a record, it will be placed in the same position where it was deleted from. If this position is already occupied with a new record, you will have the option to delete the existing record to recover the old one. This case is indicated with a value of TRUE in this field, as "Forced" means that you replaced the existing record by force. |
| • | Was Renumbered?: In the "Was Forced?" case, if you choose not to delete the new record to recover the old one, you still may recover the old record giving a new ID number to it. This case is indicated with a value of TRUE in this field, as "Renumbered" means that you change the original ID to a new valid number. This is only possible when you have an autonumber main key, and the other keys allow duplicated values. |