Subject Re: Newbie: Tracing all SQL statements
Author cdb4w
Hi Martijn,

Agreed, I have got 1 and 2 already covered.

The reason I mentioned SQL Monitor is that it is very flexible as to
what you can choose to monitor. So from a SQL DB perspective selects,
updates, inserts, deletes, performance statistics etc

Yep, its the third option that is probably the most important one of
all. Given the well documented API which I assume everything calls at
the end of the day, including ODBC drivers, this would be relatively
simple to implement.


--- In, "Martijn Tonies"
<m.tonies@u...> wrote:
> That SQL monitor hooks into to the BDE.
> There are a couple of things here -
> 1) client side SQL monitoring
> 2) client side SQL monitoring for your application
> 3) server side SQL monitoring
> Now, "2" is simple - most Firebird componentsets have some kind
> of SQL monitoring component, but they hook only your application.
> "1" should be possible as well - you should even be able to write
> a "re-rout" dll if you like.
> Personally, I think "3" is the coolest thing - together with quota
> to see which queries are "heavy" on the server etc etc...
> I don't know if "3" is being considered for Firebird 2 - but I guess
> it is, along with many many other things.
> With regards,
> Martijn Tonies