Good morning all,
I have a little SQL script that allows me to see the SQL thats going on behind the 4GL apps that our users run from a menu option. This shop (and I use that word loosely) is missing lots of source code and so it comes in pretty handy when I need to reverse engineer a report or something so I can manually recreate. Heres the script:

select username, sqx_sessionid, sqx_conbno, sqx_sqlstatement
from syssqexplain, sysscblst
where username='someuser'
and length(sqx_sqlstatement) > 0
order by sqx_sessionid DESC;

This isnt pretty, but its handy. Anyway, anyone have a guess as to why it is I can use this on 4GL apps but NOT use it to see SQL submitted form a DBAccess session? I really would like to log SQL statements submitted through DBAccess by our programming staff because they are constantly dropping tables accidentally or doing updates incorrectly and of course no one admits who did what thus my need to see a log of SQL statements! I know it sounds crazy, but I spend at least 20 hours a month restoring a database just to recover one table that a programmer was to lazy to unload before fouling up.
-thanks

Well, not to be picky, but you have presented an invalid SQL statement. There is no join between the tables.

At best you get a snapshot of the "current" SQL statement - which could be hours old. You will never see all SQL statements unless you are running them through ISpy.

If you're trying to catch programmers improperly using admin commands I suggest you look at auditing in the Trusted Facility Manual. You can set exactly which events you wish to log, like drops or creates.

Well, your right about the sql - it was just a typo. But I was thinking for some reason that ISpy was no longer an option since IBM swallowed Informix up. I have read a little abouit it and I will check it out.
-thanks