Hi Leslie,

> 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.

The API is fine - but remember, "3" was 'server side' - not at the
client.

--
Martijn Tonies

> Leslie.
>
> --- In firebird-support@yahoogroups.com, "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
> etc
> > 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