Subject RE: [firebird-support] Recording Update statements and User that executed
Author Marius Labuschagne
[Marius Labuschagne] "Hi,

Is it possible to record any UPDATE statement that is executed against a
database, from the database level?

Something very strange happened to one of my Clients databases, where one
field in a table was set to another field in the same table (both double
precision fields). I suspect that this was executed by an end user using
one of the database tools like IBExpert or Database Workbench, but there is
no way that I can prove it.

After analysis of the data and my application, I found that the particular
UPDATE that was executed is not present at all anywhere in the source code
of the application.

Regards
Marius J. Labuschagne "

Hi,

I think I could possibly use the trace manager to accomplish what I want to
track.

The section below is my database section in my fbtrace.conf file, but the
logfile is not created. Could anyone please advise me of where I am going
wrong?

I am running Firebird 2.5.2 in superclassic mode on a Windows 7 64 bit
machine.
I start the trace manager with the following command, and can see the traces
in the cmd window: C:\Program Files\Firebird\Firebird_2_5\bin>fbtracemgr -se
service_mgr -U sysdba -P masterkey -start -name my_trace -CONFIG
fbtrace.conf


<database>
# Do we trace database events or not
enabled true

# Operations log file name. For use by system audit trace only
log_filename "C:\\Program
Files\\Firebird\\Firebird_2_5\\trace_log.log"

# Maximum size of log file (megabytes). Used by system audit trace
for
# log's rotation : when current log file reached this limit it is
renamed
# using current date and time and new log file is created. Value of
zero
# means that the log file size is unlimited and rotation will never
happen.
max_log_size 0


# SQL query filters.
#
# Only SQL statements falling under given regular expression are
reported
# in the log.
include_filter %(UPDATE|DELETE)%

# SQL statements falling under given regular expression are NOT
reported
# in the log.
#exclude_filter


# Put attach/detach log records
log_connections true

# Trace only given connection id. If zero - trace all connections
connection_id 0

# Put transaction start/end records
log_transactions true


# Put sql statement prepare records
log_statement_prepare true

# Put sql statement free records
log_statement_free true

# Put sql statement execution start records
log_statement_start true

# Put sql statement execution finish\fetch to eof records
log_statement_finish true

# Put record when stored procedure is start execution
log_procedure_start true

# Put record when stored procedure is finish execution
log_procedure_finish false

# Put trigger execute records
log_trigger_start false

# Put trigger execute records
log_trigger_finish false

# Put context variable change records (RDB$SET_CONTEXT)
#log_context false


# Print access path (plan) with sql statement
print_plan false

# Print detailed performance info when applicable
print_perf false


# Put blr requests compile/execute records
log_blr_requests false

# Print blr requests or not
print_blr false

# Put dyn requests execute records
log_dyn_requests false

# Print dyn requests or not
print_dyn false


# Put xxx_finish record only if its timing exceeds this number of
milliseconds
time_threshold 0

# Maximum length of SQL string logged
# Beware when adjusting max_xxx parameters! Maximum length of log
record
# for one event should never exceed 64K.
max_sql_length 300

# Maximum length of blr request logged
max_blr_length 500

# Maximum length of dyn request logged
max_dyn_length 500

# Maximum length of individual string argument we log
max_arg_length 80

# Maximum number of query arguments to put in log
max_arg_count 30
</database>

Regards
Marius