Join 34,000+ subscribers and receive articles from our
blog about software quality, testing, QA and security.

Write log directly to a database? (Oracle in our case)


I have never liked system that log to a file. You have threading issues and file size issues, etc., etc. It just isn’t a good way to manage your logging messages.

Any change there a hook down deep someplace that we can plug in a database write procedure? It there a good message Record object, so we can break up the message into appropriate column to help with searching / organizing our message with SQL statements.

If you don’t have it, how soon will you? Would be nice to save the messages in binary form to the database and have your advanced tool read from there.




Yes! The SmartInspect libraries have a special mechanism to add custom targets/logging destinations such as databases (logging destinations are called protocols in SmartInspect). You can create your own Protocol class for writing the logging information to a database, register it and then use it like any other built-in protocol. Your custom protocol would even inherit all the common protocol options such as asynchronous logging or filtering:

Using Custom Protocols with the SmartInspect Libraries

Yes, logging information is passed as so called packets to the protocols which expose all logged information as easy to access properties. SmartInspect has multiple packet types which do different things (Log Entries are used for sending the normal messages and data, Watches send variable values, Process Flow entries carry information about the threading and process behavior and Control Commands are used for clearing/resetting the viewer application). You could simply take the properties of these packet objects and write them to your database.


Of course the next step would be to read from the Oracle database back into your monitoring tool. Is that supported? Thanks.


There is currently no built-in support for this, but you could always write a tool which pulls the data from your Oracle database and writes it to a SmartInspect log file which can then be loaded into the Console. Or, instead of writing it to a file, you could also stream the data directly to the Console via TCP/IP or named pipes. The SmartInspect log format is well documented:

SmartInspect Log Formats and Protocols

We are happy to help in case you want to write such a tool.


What about writing an interface that can use text or dbExpress sources? This would solve the problem all the way around. We are more then happy to be your alpha / beta test sight. Once you are writing / reading to a DB, threading and size issues of the file go away completely. So this is a primary concern for us going forward.

Where can I find the log format info? White paper, doc, etc. Thanks.


The documentation of the log format can be found here:

SmartInspect Log Formats and Protocols

And the following link explains how to write a custom protocol:

Using Custom Protocols with the SmartInspect Libraries

We currently do not have concrete plans to add database support to SmartInspect. It’s on our TODO list but it’s not something we are currently working on. If we decide to add database support to the libraries, we would also want to integrate complete database support into the SmartInspect Console. Since this is quite a time-consuming task, we currently cannot say if/when this feature will be available.

We are, however, happy to assist you with writing a custom protocol/tool if you decide to give it a try. E.g., feel free to email us if you have questions about the log format, protocol or implementation details and so on.


Does this look right? You are using reserved words for a couple of your column names so I had to change them. Just want to make sure I am on the right path before doing more of the entities.

TITLE_LENGTH Number(12),
DATA_SIZE Number(12),
PROCESS_ID Number(18),
THREAD_ID Number(18),
COLOR Number(12),
SESSION_NAME NVarChar2(1024),
TITLE NVarChar2(1024),
HOSTNAME NVarChar2(1024),



Looks good. I think you should be able to omit the _LENGTH fields as you can always look up the length of the strings by inspecting the corresponding string fields. Of course, it doesn’t hurt if you store the lengths separately. As an alternative or in addition to your solution, you could also save the raw binary representation of a log entry in the database. This would make it very easy to pull the data from the database and export it to a log file for the Console. You can get a binary representation of a log packet with the BinaryFormatter class.


Hi, so if my boss says “Wait, SmartInspect doesn’t write to a database!?!? Then why should we buy it???” how should I answer him? That’s actually a serious question, because I’m assuming there’s some advantage to NOT using a database, so can you explain it?


(This is the same answer I’ve sent via email)

Hello Chaz,

There are advantages and disadvantages of both approaches. I think the
two biggest advantages of log files are the ease of deployment and an
easy way to share log files.

It’s easy to deploy because you do not have to setup another logging
database or database tables, and you do not have to configure any
logging database connections and so on. Depending on how many machines
the deployed application runs on, the deployment issue can be a real

Another advantage is that you can easily copy, share and forward log
files, something that isn’t really practical with data stored in a
database. So if you have a problem on a production server, you can
easily copy or download the log in question (or ask the customer to send
it) and analyze the log file with the Console ‘offline’.

There are of course also advantages of logging to a database. Logging to
a database is easier if you are logging from multiple
processes/machines, as the database synchronizes the different logging
processes automatically.

I’m sure there are more advantages and disadvantages of both approaches,
but this really depends on the environment and the purposes of the
logging data.

We are also looking into adding database support to SmartInspect in the
future, but I cannot say when/if this gets added to the product. If
logging to a database is important, you could also just write a simple
SmartInspect protocol for your environment.