× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Yes, this is a debug-mode thing that needs to be able to be switched on by a
parameter.

Your first two ideas strike fear in my heart for the potential size of the
resulting output.

The exit point idea sounds interesting and to the point, but I've never done
one. Is there a reference you can point me to, especially if it involves
capturing SQL statements?

Thanks,
Dan

On 4/26/07, rob@xxxxxxxxx <rob@xxxxxxxxx> wrote:

Why do you need to log the SQL statements?
Debugging the program?
Troglodytes fear of SQL? Like, who'd log all SQL statements but not all
READ, CHAIN, WRITE, UPDATE, etc?

I have some ideas in mind, but I'd like to know what you are trying to
accomplish. Initial shoot from the hip ideas include:
STRDBG UPDPROD(*YES) // Note: No program name. Powerful stuff will be
in that joblog.
Journalling.
Exit point that traps all SQL statements.


Rob Berendt



Dan <dan27649@xxxxxxxxx>
Sent by: midrange-l-bounces@xxxxxxxxxxxx
04/25/2007 05:15 PM

To
"Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>

Subject: SQL diags to return actual statement executed?

(originally posted in RPG400, I decided to post here as well in case
non-RPG'ers could assist, since my question relates more to SQL
programming than RPG programming.)

Got an RPG program that does a ton of dynamic SQL INSERTs and UPDATEs,
which come from our control tables and, therefore, not actually coded in
the RPG
source. Because the statements were prepared, we were able to take the
variable used in the "Execute Immediate :SQLstmt" statement and output it
to our log file.

Now, we are taking a different tack to significantly improve performance.
Instead of using all of the dynamic SQLs, our developer has written an
application to generate the SQLRPGLE source program to do away with the
dynamic prepares. Performance improvement is dramatic but, along with
this change, we apparently lost the ability to log the SQL statement that
was
actually executed. The SQL statements still use variables, and we need to
see the statements with the variables converted in the log. We do not
know how to capture this.

A while ago, I was educated in the "Get Diagnostics" statement, and a
first poke at the documentation I thought would turn up something that
would
return the statement that was actually executed. But I was unable to find
anything. Am I looking in the wrong spot? FWIW, this is on v5r3.

TIA,
Dan

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.