Here's a reproducible...
(1) Run the following query in 188.8.131.521 dbisql:
SET TEMPORARY OPTION MAX_QUERY_TASKS = '1'; SELECT COUNT_BIG(*) FROM SYSTAB AS A CROSS JOIN SYSTABCOL AS B CROSS JOIN SYSUSER AS C;
(2) While the query is running, capture the LastStatement connection property value for the dbisql session:
select "COUNT_BIG"() from "SYSTAB" as "A" cross join "SYSTABCOL" as "B" cross join "SYSUSER" as "C"
(3) Immediately after the query has finished, capture the LastStatement value again.
In Version 16, LastStatement will still show the value in (2) above.
In Version 17, the following phantom query will appear, presumably issued by dbisql itself:
select "count"(distinct("creator" || '.' || "table_name")) from "sa_locks"("connection_property"('number')) where "table_name" <> 'EXCLUDEOBJECT'
This behavior is repetitive and
Update: Sometimes, but not always, the following inexplicable lock shows up (can't use the adjective "phantom" because that's a real thing, whereas this lock should not exist)...
SELECT * FROM sa_locks(); conn_name,conn_id,user_id,table_type,creator,table_name,index_id,lock_class,lock_duration,lock_type,row_identifier 'ddd17-2',3,'dba','BASE','dbo','EXCLUDEOBJECT',,'Schema','Transaction','Shared',
It's a feature Breck. See the new feature New visual indicator when database locks are present.
I unfortunately do not yet see a way to disable it (short of using dbisqlc or pre-V17 admin tools) and while it would appear to be randon it does appear to be executed only at times where it would matter (new connections, new tabs, DML operations, ... from my limited testing)
answered 19 Nov '15, 18:25
Nick Elson S...