Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 5 of 5 total
Thread Query logging
Fri, Jan 25 2013 2:14 AMPermanent Link

jwtm

I am sure the EDB  server suports query logging, but I can't find the subject in the manual.

How do I enable query logging and how do I examine the logs?
Fri, Jan 25 2013 11:04 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com


<< I am sure the EDB  server suports query logging, but I can't find the
subject in the manual. >>

EDB supports logging/tracing of queries and other requests via the client
only.  Perhaps I can give you a better solution: what are you trying to
examine, or why are you trying to log the queries ?

Thanks,

Tim Young
Elevate Software
www.elevatesoft.com


Sat, Jan 26 2013 3:12 AMPermanent Link

jwtm

"Tim Young [Elevate Software]" wrote:

<< I am sure the EDB  server suports query logging, but I can't find the
subject in the manual. >>

EDB supports logging/tracing of queries and other requests via the client
only.  Perhaps I can give you a better solution: what are you trying to
examine, or why are you trying to log the queries ?

Tim Young

I am looking at a large application I didn't write which has DBMS-associated performance issues. So the first thing I want to do is log all DBMS communications, with timestamps, to see if the DBMS is being used inefficiently -- e.g. too many queries -- or if the DBMS is slow in processing the queries it gets, and so on. I don't want to hunt all over the application to log queries wherever they are generated, so logging by the server would be my my first choice.

The next would be to set a client-side hook to log outgoing queries and their responses. Is there such a hook in the Elevate component?

I have other reasons to want to log queries -- e.g. to inspect for injection points, and to see if any queries could be replaced by stored procedures.


Sun, Jan 27 2013 7:25 PMPermanent Link

jwtm

jwtm wrote:

I am looking at a large application I didn't write which has DBMS-associated performance issues. So the first thing I want to do is log all DBMS communications, with timestamps, to see if the DBMS is being used inefficiently -- e.g. too many queries -- or if the DBMS is slow in processing the queries it gets, and so on. I don't want to hunt all over the application to log queries wherever they are generated, so logging by the server would be my my first choice.

The next would be to set a client-side hook to log outgoing queries and their responses. Is there such a hook in the Elevate component?

I have other reasons to want to log queries -- e.g. to inspect for injection points, and to see if any queries could be replaced by stored procedures.

======

Ok, found the client-side logging hook in the manual. When all else fails, read the manual. No need to answer this, but if you do have opinions about what I am attempting to do, I will read them with interest.




Mon, Jan 28 2013 3:54 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com


<< Ok, found the client-side logging hook in the manual. When all else
fails, read the manual. No need to answer this, but if you do have opinions
about what I am attempting to do, I will read them with interest. >>

Yep, TEDBSession.RemoteTrace/OnRemoteTrace is what you want.  The benefit of
client-side tracing is that a lot of "performance issues" are not EDB engine
issues, exactly, but rather issues with too many round-trip request/response
calls to the EDB Server.

I usually recommend that you pop a stay-on-top form in your application that
has a TMemo on it, and then just log the OnRemoteTrace events directly to
the memo in real-time.  That's the easiest way to see exactly what's going
on as the application is used.

If you see a lot of Locate calls, then most likely you've got a lookup
fields/calculated fields issue.  Those can both cause the problem with too
many round-trip calls because they fire constantly whenever the active row,
source field, or dataset changes in any way.  The best way to cure this, at
least with lookup fields, is to cache the lookup datasets by setting the
TField.LookupCache property to True.

If you have any other questions, please let me know.

Tim Young
Elevate Software
www.elevatesoft.com
Image