Tuesday 18 February 2020

Cannot reproduce (sql - maybe alias related) reply

Cannot reproduce. (alias related issue)

Get back to the customer.

We should have a standard reply if we cannot reproduce the sql error I will try to give one:

1/sql command has -verbose flag which show issues (like java or sql exceptions) that have been logged.

2/"set echo on” might help (unlikely though - it will echo out what commands the alias is doing)

3/Things that might not be accounted for in customer ‘aliases.xml’ test case: 

.login.sql file or equivalent automatically read at startup
set sqlformat
The bug is logged against linux (that is what I tested on and could not reproduce)
Might need a full:
sql username/password @thetestcase.sql
Testcase (with aliases xml and .login.sql if any) in case anything before the alias in the session and or customer environment is required to reproduce.
What is the encoding/language? - ie is it UTF8 + American (English) (Some bugs are multibyte is Japanese/Chinese only)

Try with latest oracle java 8 (not openjdk) and ORACLE_HOME unset i.e. thin driver as shipped instead of thick driver from Oracle home. (What is the show JDBC and show java output?)
(What is the oracle database version being connected to and what Oracle Database does $ORACLE_HOME point too?)

4/Can the customer reproduce with new operating system user/different linux box?

5/Has the database connection timed out (Oracle ADB does that) - or other too much resource used and connection cut off by the database dba/automatically, - unlikely as the command works on repeating it (could be a reconnect)

6/The error says ctrl C - however there could be another error caught and reported wrong/differently

If I had a test case I would go through the code line by line.
Without the code If I could reproduce I would do some tracing (strace/wireshark) - but I cannot expect customer to do that - too much in the tracing file/output to go through - in sqldeveloper there is a log view which at least gives all the sql sent to the database (slightly more user friendly than strike/wireshark). There might be other tracing the customer is aware of/more familiar with, Unless encrypted or https - the sql to and error back from database is sent received by a write/read from file/socket (and unencrypted).