Hello again Gary,
I think I have figured it out (partially).
We do not see this information for the queries, no matter what they consume in case they run from a stored procedure.
I did this little test with 3 session on my own:
DDLs:
CREATE SET TABLE DataLab03.aaaa ,NO FALLBACK ,
NO BEFORE JOURNAL,
NO AFTER JOURNAL,
CHECKSUM = DEFAULT,
DEFAULT MERGEBLOCKRATIO
(
col1 INTEGER,
col2 INTEGER,
col3 INTEGER)
PRIMARY INDEX ( col1 );
REPLACE PROCEDURE datalab03.testproc()
sql security creator
begin
proc:
begin
delete from datalab03.aaaa;
end proc;
end;
1. session:
bt;
lock table datalab03.aaaa for write;
2. session:
call datalab03.testproc();
3. session:
delete from datalab03.aaaa;
The 1. session holds the lock and I keep the transaction open in order to keep the other 2 blocked.
I observe that I never get SQL info for the 2. session, but get SQL infor for the 3. session (most of the time - but not all always).
The question now is - is this intended?
GLHF,
Yuri
Hello again Gary,
I think I have figured it out (partially).
We do not see this information for the queries, no matter what they consume in case they run from a stored procedure.
I did this little test with 3 session on my own:
DDLs:
CREATE SET TABLE DataLab03.aaaa ,NO FALLBACK ,
NO BEFORE JOURNAL,
NO AFTER JOURNAL,
CHECKSUM = DEFAULT,
DEFAULT MERGEBLOCKRATIO
(
col1 INTEGER,
col2 INTEGER,
col3 INTEGER)
PRIMARY INDEX ( col1 );
REPLACE PROCEDURE datalab03.testproc()
sql security creator
begin
proc:
begin
delete from datalab03.aaaa;
end proc;
end;
1. session:
bt;
lock table datalab03.aaaa for write;
2. session:
call datalab03.testproc();
3. session:
delete from datalab03.aaaa;
The 1. session holds the lock and I keep the transaction open in order to keep the other 2 blocked.
I observe that I never get SQL info for the 2. session, but get SQL infor for the 3. session (most of the time - but not all always).
The question now is - is this intended?
GLHF,
Yuri