Queries executed on wrong database on Informix (again)

Hi all, I have another bug to report, and it's a child of these two: http://www.dbvis.com/forum/thread.jspa?messageID=17057 http://www.dbvis.com/forum/thread.jspa?messageID=15464 Prerequisites: - an informix instance with 2 or more databases (mine are called "backoffice" and "warehouse") To reproduce: 1. Create informix database connection, set default database to "backoffice". I have something like "jdbc:informix-sqli://azra.zse.hr:1526/backoffice:informixserver=zse_dev" 2. Open tab, select "warehouse" database, enter several queries, e.g.: select * from systables; select * from systables; select * from systables; 3. SSH to database server and kill all connections established by DbVis: - "onstat -g ses" will list all active sessions, - identify your sessions established by DbVis - kill them using "onmode -z ###" (replace ### with session ID) This is equivalent to waiting until the connections timeout and are terminated by the server which happens after a while of idling. 4. Back in DbVis, select all three queries and execute them (Ctrl+Enter) Expected: Well, I wrote what I'd like to happen in the previous bug report, but that isn't fixed yet. So what I expected is that first query fails, and second and third query are executed. What actually happens is a bit more interesting. Actual: The first query fails, as expected, producing "System or internal error java.io.IOException". Then DbVis re-establishes the connection, and selects the default database ("backoffice"). Second and third queries are then executed on the default database, instead on the one I selected. Here's the log, it's not very helpful: --- ERROR: 13:30:51 [SELECT - 0 row(s), 0.000 secs] [Error Code: -79716, SQL State: IX000] System or internal error java.io.IOException INFO: ... Physical database connection acquired for: Backoffice Development (informix) INFO: 13:30:51 [SELECT - 464 row(s), 0.000 secs] Result set fetched INFO: 13:30:52 [SELECT - 464 row(s), 0.000 secs] Result set fetched SUMMARY: ... 3 statement(s) executed, 928 row(s) affected, exec/fetch time: 0.000/0.046 sec [2 successful, 0 warnings, 1 errors] --- Please, fix this. For me it's ieprative that I know which database I'm executing queries on. If I can't be 100% certain then I cannot use DbVis for accessing production databases in case I do something horrible. Best regards, Ivan Product: DbVisualizer Pro 9.1.2 Build: #2072 (2013/10/28 18:25) Java VM: Java HotSpot(TM) Client VM Java Version: 1.7.0_11 Java Vendor: Oracle Corporation OS Name: Windows XP OS Arch: x86 OS Version: 5.1

Ivan, Apologies for not fixing these issues yet. I can reproduce your latest scenario and will try to get a solution for all of them into the next maintenance release. Best Regards, Hans

Ivan, I believe I have found a solution for the the problem you describe here and the problem you described in: http://www.dbvis.com/forum/thread.jspa?messageID=17057 For both these cases, the execution of your example script would stop with this message after attempting the first statement: select * from systables; 16:16:11 [SELECT - 0 row(s), 0.000 secs] Database connection is not open ... 1 statement(s) executed, 0 row(s) affected, exec/fetch time: 0.000/0.000 sec [0 successful, 0 warnings, 1 errors] You would then have to reconnect and run the script again, and the selected non-default database would remain set in the SQL Commander. Would this work for you? In a future version we hope to improve this so that the connection icon would also indicate that the connection has dropped and you would be prompted to reconnect when executing the script. This will, however, require more code restructuring that we like to do in a maintenance release. I also realized that a better work-around for both these issues is to open Tool Properties, select the SQL Commander category and enable Stop on Error. That would give pretty much the same behavior as I described above already with the 9.1.2 version. I will take another look at http://www.dbvis.com/forum/thread.jspa?messageID=15464. Can you please confirm that the work-around we suggested for that problem still works in 9.1.2? Best Regards, Hans

Hi, Yes, the described fix would be good enough. Any later improvements are welcome. Until then I will enable Stop On Error. Concerning http://www.dbvis.com/forum/thread.jspa?messageID=15464 , I thought that was fixed and there's no need for the workaround any more. Regards, Ivan

Hi Ivan, You're right about http://www.dbvis.com/forum/thread.jspa?messageID=15464. I have taken a closer look now and it is indeed fixed. I thought maybe there was still something to be done there since you included in your first post in this thread. Best Regards, Hans

I was just referencing it since it was similar. Sorry for the confusion. Regards, Ivan