This procedure provides a standardized mechanism to log information to a standard log table.  This procedure accepts multiple rows of data to be logged in the form of a User Defined Table Type.  This allows the procedure to load multiple rows at the same time for better performance.  Since information is held in a table variable the log data can carried across transactional boundaries. This allows for the logging of information captured inside a transaction that was rolled back to be logged outside of the original transaction. The procedure provides the ability to be resilient in the face of errors not passing those errors up the stack if so desired.


udb.logInsertTableVariable [@logging_table]=logging_table


[@set_id=] uniqueIdentifier



Table variable that contains the information that is to be logged.  Please see udb.logging_table for structure and descriptions.  Multiple rows of data can be passed through this variable.


The bit is used to determine if a error in this procedure should be raised or silently caught. 0=Internal error messages will be captured by a try catch block and not raised. 1=Error messages will be raised.  Default value of 1.

[@set_id=] uniqueIdentifier

A unique value to identifier a calling processes, procedure, group of procedures.  Use the same value across multiple procedure calls if you want to tie the process together in the log table. This could give the view of procedures call one after the other or nested inside each other.

Return Codes

0 (success) or 1 (failure)

Result Sets



This procedure serves a dual special purposes in the logging of information.  First it is a high speed logger for logging many rows of data when compared to multiple executions of the udb.logInsert procedure.  Second it accepts a table variable.  If the table variable is populated inside a transaction and the transaction is rolled back the table variable is unaffected.  The information can then be passed to the udb.logInsertTableVariable to be logged.  In affect this allows for information collected inside a rolled-back transaction to be captured allowing for debugging when otherwise the transaction would have cleaned any information that maybe helpful in the debugging process.  If one of these two special purposes is not required best practices lead to the use of the udb.logInsert procedure for logging.



See Also




Last edited Jan 11, 2014 at 1:00 PM by sfibich, version 3


No comments yet.