I am Bikku, I want to know how to enforce TMF to take care of audit
files programmatically.
Is it different for SQL and ENSCRIBED files?
Hi Bikku,
I think you understood something wrong: With setting the auditflag to
true TMF will care of the file/table and you are forced to pay
attention to this in your program. And yes, there are differences
between Enscribe and SQL. With Enscribe, you have to call
BEGINTRANSACTION to start update processing and ENDTRANSACTION if you
updates are finished. This is valid for SQL, too. But with SQL you
usually use BEGIN WORK and COMMIT WORK. With SQL, you can ommit this,
then SQL itself will take care of transaction handling, but from my
experience this is very dangerous because you know when your
transaction is finished, SQL doesn't. By the way, for readonly access
you do not need to start a transaction.
The above is all correct. It just occurs to me that you might be asking how to turn on the audit flag from within a program rather than how to start and end transactions. If that is not what you wanted to know, ignore the rest of this email.
For an existing Enscribe file, one uses the FILE_ALTERLIST_ (or the older ALTER) Guardian procedure to change the audit flag. If the program is creating the file, audit is one of the attributes that can be set among the parameters to the FILE_CREATE_ or the FILE_CREATELIST_ (or the older CREATE) procedures. All these procedures are described in the Guardian Procedure Calls Reference Manual.
For existing SQL/MP tables, one uses an embedded SQL ALTER TABLE statement to change the audit flag. If the program is creating the table, the embedded SQL CREATE TABLE statement can set the audit flag at the time the table is created.
SQL/MX tables are always audited, so one cannot turn the audit flag on and off for them.
Note that all these methods of turning on the audit flag turn it on permanently until some action is taken to turn audit off again. That is, there is no way to turn on audit temporarily, so that it is automatically turned off when the program stops.
You can, with "mxtool fixup"
Bye, Jojo
I did not know about that. Thanks for the information.
I just read the description of mxtool fixup, and it appears that it is intended that one turn off audit only when doing some sort of low-level patching of the file structure, then turn it on again before resuming normal use of the table. Do you know whether one is able to perform regular SQL statements (DML or DDL) on a SQL/MX table when it is not marked audited? For instance, if one forgets to turn on audit after doing a repair and tries to access the table normally, will that return an error, or perform the operation without auditing?
I believe it will just perform the operation without auditing. But when in
doubt, try it out 8-)
Bye, Jojo