Translating with DrWatson… this can take a few seconds the first time.
This is a genuine, complex translation. DrWatson protects commands, error codes, and log output while naturally translating the surrounding text. It’s translated once and saved.
Alexander Ivanov (14.10) could not see his INSERT with onstat -g sql for a session holding locks, only a sysopendb query. Andreas Legner said the locks belong to the transaction, not the statement, and onstat -k shows the DML type. Mike Walker thought the shown query came from his client tool. Using dbaccess showed the expected result. His onstat -k column appeared empty.
Auto-generated by Claude from the posts below — may be imperfect; read the full thread.
Alexander Ivanov — source: IBM Community (ConnectedCommunity.org) Informix forum
Hello.
I have Informix 14.10.
I started the session and checked
DBINFO('sessionid').Then in that session i ran:
BEGIN;
INSERT INTO ttt VALUES(1);In another session i ran
SELECT * FROM syslocks;and see 2 locks on my table and the owner is my sessionid.
I was expecting that when i run onstat -g sql sessionid i will see my Insert command, but I see
SELECT ODB_DBName FROM SysMaster:"informix".SysOpenDB WHERE ODB_SessionID= DBINFO('sessionid') AND ODB_IsCurrent = 'Y'
How i can see the real querry that is locking my table?
------------------------------
Alexander Ivanov
------------------------------
#Informix
↪ replying to Alexander Ivanov
Andreas Legner — source: IBM Community (ConnectedCommunity.org) Informix forum
(Not sure where this sysopendb query comes from or why it's being shown ... it probably is irrelevant here.)
It's not the INSERT statement that holding those locks, but the surrounding transaction. The INSERT, if it was the last statement in this session might still be visible as 'last parsed SQL statement', but there could as well have been N other statements running since that particular INSERT.
What you're typically interested in is which session is holding a given lock, and then maybe whether the lock originates from an INSERT, UPDATE or DELETE. The latter you could see from 'onstat -k' -> DML column.
------------------------------
Andreas Legner
------------------------------
↪ replying to Alexander Ivanov
Mike Walker — source: IBM Community (ConnectedCommunity.org) Informix forum
I have seen this same statement used before in stored procedures - it is simply getting the database name for your connection.
Assuming that you haven't run any more SQL in the first session where you performed the insert, then I'd see if there are any triggers on the ttt table (unlikely if this is just your own test table).
What are you using to connect to the database and run the SQL? If you are using some tool or application to query the database other than dbaccess, then it may execute its own SQL. Are you connecting through a web server or app server?
Try using dbaccess on the server itself and see if you get the same results.
------------------------------
Mike Walker
xDB Systems, Inc
www.xdbsystems.com
------------------------------
↪ replying to Mike Walker
Alexander Ivanov — source: IBM Community (ConnectedCommunity.org) Informix forum
Thanks.
Really whe I use dbaccess I can see expected results.
------------------------------
Alexander Ivanov
------------------------------
↪ replying to Andreas Legner
Alexander Ivanov — source: IBM Community (ConnectedCommunity.org) Informix forum
For some reason DDL column is empty in onstat -k result.
------------------------------
Alexander Ivanov
------------------------------
We use strictly necessary cookies to make this site work. With your
consent we’d also use optional cookies for analytics and marketing. You can accept all,
reject all, or choose. Read our Cookie Policy.