Markus Kemper wrote:

>
> There have been numerous cases where it would have
> been handy to simply query the interbase.log file
> vs. scroll through it looking for hints of problems.
>
> At first I thought it would be nice to convert it
> to an InterBase database on the system but, then
> thought that might be overkill and too much overhead.
>
> How about writing the file and its messages to disk
> in a preformated (fixed length) fashion so that the
> log could be referenced and queried via an InterBase
> external file?
>

I think this is a great idea.

How about:

create table InterBaseLog external %interbase%\interbase.log (
LOG_DATE CHAR(21), /* YYYY-MMM-DD HH:NN:SS */
TIER CHAR(7), /* CLIENT or SERVER */
SERVER CHAR(32), /* How big can a server name be? */
NEWLINE1 CHAR(2), /* platform dependant */
INCIDENT CHAR(256) /* How big can a message be? */
NEWLINE2 CHAR(2),
NEWLINE3 CHAR(2)
)

Server names can theoretically be pretty big. They should go at the end of the
first line and be as long as we want. (128? 256?).

Human readability will remain critical, I believe, hence NewLine1 to ensure that
the Incident message should still appear in a text viewer without having to
scroll horizontantally.

Presumably an incident of 256 chars is enough.

Two problems come to mind. The first is portability. How is an external table,
declared in a database running on NT going to 'know' it should have a different
newline length if restored on Linux, say.

And just where are we going to put declare this external table. It is a server
thing, not a database thing. Perhaps a candidate for isc7.gdb?

Paul
--

Paul Reeves
Fleet River Software
/***************************************************************************
* v1.0 of the InterBase Heartbeat - Database Monitor is now available. *
* Visit http://www.fleetriver.demon.co.uk to download an evaluation copy. *
***************************************************************************/