[Info-ingres] Snooping on another user session

[Chris...@actian.com]

On Tuesday, October 6, 2020 at 2:58:04 AM UTC-7, Martin Bowes wrote:
...
> The error experienced by one (and only one) user would indicate they have connected with date alias of ansidate. Yet a scan of their client config says that should be ingresdate. I’ve trapped their connected activity with sc930 on the two installations on which the application is working but have not found any resetting of the date alias with a set date_alias ‘ansidate’ either. 
> Having looked at the session trace, I can provoke the error using a terminal monitor connection, but only if I set date_alias ‘ansidate’.

It seems likely the setting is being set on the client side somehow and you want to prove one way or the other which it is.

If this is a specific user and a libq based client I would recommend setting II_EMBED_SET client side to printgca and asking them to run the application and send the iiprtgca.log - super easy to read compared with other tracing options. Tracing also means the SQL actually used can be seen (as well as possible errors).

If either of those assumptions are incorrect, I'd likely still go the GCA trace route but do it a different kind/place. You can decide if that's client or server depending on what you you know about the client. Docs have some notes on this, https://communities.actian.com/s/article/GCA-Trace-Logs-without-Tears-Ingres-II-and-OpenIngres-only is a pretty good server side one (you can always spin up a new GCC server for this specific user so as to avoid tracing everyone).

Unless you can ensure the encryption is not in play, I would avoid raw tracing the socket or wireshark. If encryption is not enabled then you can use your favorite network sniffing technique :-)

Its probably worth opening an enhancement request for server side checking of session sessions (in IMA).