Re: Stored Proc execution times, front to back

On 15-Oct-2016 01:22 -0500, D*B wrote:

On 14-Oct-2016 12:19 -0500, Needles,Stephen J wrote:

[…] In the program that is the stored proc is an SQL statement. When I
test the statement alone, I can route its output to a table and
clock the whole process.
But when I try to do the same thing using the stored procedure, I
am not allowed. […]

- grant public write access to your log table
- use a stored procedure, running under owner for logging
- write the information to the joblog via QMHSNDPM
- if it's for test and verification only, use Database Monitor
(STRDBMON) to get the information

But all of those possibilities would seem to ignore, [I suppose appropriately, given] what was snipped from the OP; i.e. what defined the "whole process" was; with emphasis my own, for the missing quoted text that is reinserted below:

I need to be able to find out how long it takes to execute a
stored procedure, all the way through the open *and consumption*
[of] its cursors.

Thus the expression of the request, further clarified as:

Does anyone have an idea that can allow me to do something like:

Insert into testable (call storedProc(parameter))

This would include the creation (inside the storedProc)
*and consumption of the cursor* (the INSERT portion)

Measuring only the open of the cursor, is not the same as having measured that inclusive of fetching all of the data from that cursor.

Of course for a similar reason to why comparing the query defined by the cursor to the stored procedure is not accurate for determining performance, nor is dependence on some little known feature performing the fetches versus the specific feature that would normally consume the result set. For example, if the actual-consumer does single-row FETCH requests, and the feature introduced as an alternate consumer for the testing with the purpose of /mimicking/ the actual-consumer, how would that help determine how well the actual-consumer performs? Not so well.

and iNav should be able to tell how long it took to run.

The offered alternatives are probably best, in response to just the above snippet; i.e. no reason to limit gathering the timing information using the iNav, coded as an INSERT or otherwise, when there are innumerable other ways.