|
Here's a reproducible... (1) Run the following query in 17.0.0.1211 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) HTH
2
Would it not be more appropriate if such a "monitoring query" would run as a separate connection - thereby preventing the LastStatement connection property from becoming somewhat worthless?
(20 Nov '15, 05:56)
Volker Barth
Adding an additional separate connection to dbisql for this was something I had thought of too ... [but I can think of lots of big solutions for small features all day long so the fact that I thought of that as well is not a very good measure of that being a good idea] FWIW As a feature LastStatement may not represent what you are interested in for admin tools. Many [3rd party] dev. tools and admin tools will pepper the connection with lots of meta-queries like this. Specifically with dbisql, there are lots of other actions that occur in the background that can confound this feature in other ways. Even outside of the dev. and admin tools the LastStatement property can became ineffective (for some purposes) for reasons other than just this (framework-, api-, metadata interaction) activity. Client side statement caching, long term multiple reuse of prepared statements, overlapping prepares and concurrent fetches across multiple cursors from same connections can all confound the meaning of this property. Maybe the better answer for all of this would be a much larger feature than just this one property. But I'm sure none of this hasn't changed Breck's requirements or opinions much. HTH Cheers
(20 Nov '15, 10:00)
Nick Elson S...
OK, it's official... Watcom no longer does things the way they should be done. A sad day for all.
(20 Nov '15, 16:11)
Breck Carter
|
