 |
Developer Name: |
Carlos Perez |
 |
Company Name: |
|
 |
Email Developer: |
Email Developer |
 |
Latest Version: |
0.9 |
 |
Price: |
$100 |
 |
License: |
One Copy per Server. |
 |
Encrypted: |
Yes |
 |
Average Rating: |
 |
 |
Times Rated: |
2 |

Tag Comments
|
There are no comments for this tag yet!
|
|
What Is SQL Audit Control System? |
|
A system that automates the process of creating trigger-based history tables on SQL database user defined tables. |
About SQLACS
SQL Audit Control System is a system designed simply for one task: the creation of trigger-based history tables.
Many business systems require compliance with "21 Code of Federal Regulations Part 11: Electronic Records and Signatures" (AKA: "21 CFR Part 11"). It is also often convenient to have a history of past transactions for trace-ability purposes.
This system is designed to "plug and play" on your web server, and will enable you to create complete history records on just about every table in your system whether it is a Cold Fusion application front end or any other front end with a SQL database.
Because it uses triggers to automate the process of logging INSERT and UPDATE transactions and even DELETEs (see below), it saves hours and even days of grueling programming trying to do it yourself by programming.
Glossary of Terms
User Table: A user-created table in the working database
Audit Table: A table created to store audit data whenever changes are made to records in the corresponding user table
Registered Datasource: The name of a datasource as registered in the ODBC.INI setting of the server's registry. Only SQL data sources should be shown.
Current Working Datasource: The name of the datasource that is currently being displayed
Actual Database Name: The name of the actual database that the Current Working Datasource maps to
Audit Status (Enabled): States that auditing is already enabled for the indicated table
Audit Status (Not Enabled): States that auditing is NOT already enabled for the indicated table. Although there may exist an audit table for the source table, this status will exist if there is no trigger to function for that audit table. If in question EXAMINE THE DATABASE before making any changes here.
Steps to Create an Audit Table
1) Choose the datasource you wish to work with on the right -->
2) Choose CREATE or CREATE W/DELETE for each of the tables you require to be audited
* CREATE: Simple Audit * CREATE W/DELETE: Delete bit field is created that allows deleted records to be recorded before removal 3) Verify that the audit features have been enabled by examining the database recordset more closely
Notes
DELETE: When you delete records from a database they are gone forever. With SQLACS you create an audit system in your database that eliminates the problems associated with record deletes by essentially providing you another avenue for doing so. By using the CREATE W/DELETE function, you turn on the ability to perform an UPDATE that will both record AND delete a record, allowing you to delete records while ensuring that no data is every actually lost.
Why delete records? It's much easier to SELECT * on a table than it is to SELECT * WHERE doNotShow = 1.
Why NOT simply delete records? There is no history of when the record was deleted, nor is that data retrievable in the future for audit purposes.
Why use CREATE W/DELETE? When you CREATE W/DELETE, SQLACS creates a special trigger function associated with the value of a bit field called "A_deleted" (by default - can be changed in code) that when set to 1 (true) fires a trigger that archives the record and then performs an actual delete. This two-step process ensures a complete history table while allowing you to keep your program code short and unambiguous for future coders.
|
|