Re: Result set not displayed in INav Run Sql Scripts..

On 31-Oct-2011 12:00 , Robert Rogerson wrote:

<<SNIP>>
I have a colleague that is running the exact same stored procedure
that I am but she does not see the result set in Run Sql Scripts.

We are both using V7R1M0.

When each of us run the stored procedure on the messages tab it
shows:

CALL CANLIB/GETSTOREINFO( 'O', 1, 0, '', '', '', '', '', '', 0, '')
Return Code = 0

SQL State: 0100C
Vendor Code: 466
Message: [SQL0466] 1 result sets are available from procedure
GETSTOREINFO in CANLIB.
Cause . . . . . : Procedure GETSTOREINFO in
CANLIB was called and has returned one or more result sets.
Recovery: None. Statement ran successfully, with warnings (391 ms)

But on my CALL CANLIB/GETSTOREINFO('O', 1, 0, '', '', '', '', ''
, '', 0, '') tab many rows are shown. On hers, no rows are shown.

We've looked at her QZDASOINIT job but there are no messages or
errors. Both our QZDASOINIT jobs have the same messages.

Does anyone have any idea what may cause this?

Some possible, perhaps improbable, origins for difficulties; each dependent on options [e.g. naming] used to create the procedure or the procedure source:

Unqualified TABLE\data reference; e.g. data referenced in the stored procedure results in data coming from different sources due to different library list or CURRENT SCHEMA.

Unqualified routine reference; e.g. UDF referenced in the stored procedure has different results or references data from different sources due to different PATH.

Special registers in selection; e.g. different USER or CLIENT-specific details causing different selection against the same data.

Data is locked or not visible; e.g. data is under isolation and held in the first invocation. The SKIPPED LOCKED DATA would explicitly avoid waits [¿and errors?] on locks; although WAITRCD can be small, I believe row-locking errors would be logged and shown in the CL:dspjoblog output, though not for skip.

Stored procedure updates selected data; i.e. the first invocation changed data in a manner that precludes the same data from being selected with the same WHERE clause.

Connection to the wrong database.

Regards, Chuck