Hans,
My working theory at the moment is that I think that when a connection has an issue - e.g.:
2016-05-28 06:07:37.098 INFO 663 [ExecutorRunner-pool-3-thread-1 - L.?] Error executing: database sysadmin for: UADB1 Prod3
java.sql.SQLException: No connect permission.
...that somehow at that point the isolation mode gets lost/forgotten for that database connection.
Hence when DbVis runs the select to access my table, I see this sort of behaviour:
2016-05-28 06:08:24.765 FINE 663 [pool-4-thread-1 - B.?] RootConnection: IfxStatement.execute("SELECT * FROM informix.autochgtran")
2016-05-28 06:08:24.766 FINE 663 [pool-4-thread-1 - B.?] RootConnection: EXCEPTION -> java.sql.SQLException: Could not do a physical-order read to fetch next row.
No real proof of this yet, but I noticed in the logs of sessions that failed, there's always an error in the log (between the point of connecting to the database and the point of selecting from the table I'm trying to access). When my SQL is successfully executed (e.g. using SQL commander with individual connections), I don't see any errors...
So perhaps there is an issue with the JDBC driver??? Even so, I'm wondering why DbVis is trying to accessing the databases it does when trying to access the Data tab for a table (it's these unexpected accesses that are leading to the "No Connect Permission" errors).
e.g. I'm accessing the AutoChgTran table in database BBS, but in the logs I'm seeing a failed attempt to access the sysadmin database (see the first log snippet above). Why is DbVis accessing that table?
I've attached the full log FYI...
Data corruption and inconsistency are possible risks associated with accessing records that haven't been committed. It might result in inaccurate or lacking data being obtained, which could have an impact on later transactions. For database operations to continue being dependable and consistent, it is essential to ensure data integrity through appropriate transaction management.
Hi Scott,
I just wanted to let you know that we have released DbVisualizer 9.5 today with a fix for the issue you reported. Please upgrade to the latest official version. Easiest is that you open Help->Check for Update in DbVisualizer to perform the upgrade.
An alternative is that you download from our web site:
http://www.dbvis.com/download/
Best Regards,
Hans
Hi Scott,
Great, thanks for confirming.
Best Regards,
Hans
Thanks Roger - I can confirm that 95.2559 worked as expected...
Scott,
We've just released DbVisualizer 95.2558 BETA which includes a fix for this issue. Easiest to upgrade is to open Help->Check for Update in DbVisualizer.
Regards
Roger
Hi Scott,
Thanks for all your help with this! You're right, it is a bug. The changes we made in the latest Beta made it more obvious but the same issue has been there for a very long time, and can be seen if you set the isolation level and then expand a database node that is not the default database. This resets the isolation level and any settings done via a connection hook.
I've opened a ticket for looking into a solution for this. For now, your work-around with "Show Only Default Database/Schema" should be fine.
Best Regards,
Hans
Hans,
Using version 9.2 worked as expected. So does the 9.5 beta, provided I enable the "Show Only Default Database/Schema" option. As soon as 2 or more databases are enabled for a particular connection (in the Beta version) the issue starts...
FYI, I've attached the logs for both the 9.2 and 9.5 Beta versions with both a single database and with multiples visible for the connection.
NB: I've added extra blank lines in the logs (to make it easier for me to compare them to each other)
Hi Scott,
Since you reported this in the Support forum, I thought you were getting this with DbVisualizer 9.2.15, but I now see that you are using the Beta version for this test. In the Beta, we try to connect to all databases to get the schema names. This is why you see the failed attempt to connect to sysadmin. You may be on to something here...
We do not do this in the DbVisualizer 9.2.15, so please test this with that version so we can verify if the problem you see is related to the new Beta behavior.
Best Regards,
Hans
Hi Scott,
Okay, then Single Shared Physical Connection will not help. I'm afraid I'm out of ideas, so please see if you can get help in an Informix forum. If you find a solution, please let us know.
Best Regards,
Hans
Hans,
FYI, when I'm testing, I'm locking the table complete externally to DbVis (using the Informix dbaccess tool). In dbacesss I'll enter a command like:
BEGIN;
DELETE FROM TABLE xxxxx;
and then I go an test in DbVis...
Hi Scott,
How transaction isolation and locks work is very database dependent and I'm by no means an expert, so you may need to ask for help in an Informix forum.
What I can tell you about DbVisualizer is that each SQL Commander tab uses its own physical connection, so with Auto Commit off, you should always be able to see uncommitted changes made in the same SQL Commander, regardless of transaction isolation level. The tree and Object View tabs, like the Data tab, use a separate physical connection, so that's where transaction isolation and locking comes into play. One would think that with TRANSACTION_READ_UNCOMMITED, the connection for the Data tab would be able to read uncommitted changes made over an SQL Commander connection, but that does not seem to be the case for Informix. I don't get the exact same error message as you, but I also am not able to read the table in the Data tab.
If you need to work with uncommitted data in multiple tabs, you may need to use the Single Shared Physical Connection feature:
http://confluence.dbvis.com/display/UG92/Using+a+Single+Shared+Physical+Connection
I suggest you first try to get help in an Informix forum, and then try Single Shared Physical Connection if needed.
Please let us know what you find.
Best Regards,
Hans
Hans,
Today SQL Commander seems to be working fine (regardless of the Auto Commit setting at either the connection level or the SQL commander levels). I'm not sure what's changed to make it work yet, but I have attached the log file from yesterday (when it didn't work) just in case there's something there that looks odd to you...
Regardless of SQL Commander working ok or not, the Auto Commit setting for the connection makes no difference when I access the records for a table - I still can't view data on the "Data" tab and nor can I get a count on the "Row Count" tab.
Hi Scott,
Odd. Is Auto Commit enabled or disabled for the SQL Commander (and/or for the connection as such in the Connection tab)? Does flipping it make a difference?
Best Regards,
Hans
anonymous
When I try to access records on an Informix database that are not yet committed, I'm getting an error ("[Error Code: -245, SQL State: IX000] Could not position within a file via an index. 2) [Error Code: -144, SQL State: IX000] ISAM error: key value locked").
I know I need to set the isolation mode and so doing this (in SQL Commander) works - e.g. this is OK:
set isolation to dirty read;
select * from sp_cn_chg where chg_code = 'POST';
However, I have actually entered "set isolation to dirty read;" into "Database Connection Hooks", "Run SQL at Connect" setting on the properties tab for the connection and so I don't understand why I need to explicitly add it into the SQL Commander session.
I can see in the logs that the the "set isolation" command is actually run:
2016-05-25 17:26:41.553 FINE 697 [ExecutorRunner-pool-2-thread-1 - AbstractFacade.executeCommand] Executing 'SET ISOLATION TO DIRTY READ'
2016-05-25 17:26:41.553 FINE 697 [pool-3-thread-1 - B.?] DefaultEditor21: IfxStatement.execute("SET ISOLATION TO DIRTY READ")
...but the SQL executed fails:
2016-05-25 17:26:41.570 FINE 697 [pool-3-thread-1 - B.?] DefaultEditor21: IfxStatement.execute("select * from sp_cn_chg where chg_code = 'POST'")
2016-05-25 17:26:41.580 FINE 697 [pool-3-thread-1 - B.?] DefaultEditor21: EXCEPTION -> java.sql.SQLException: Could not position within a file via an index.
NB: This behaviour also means I can't look at the records in the "Data" tab for table that currently has uncommitted data (which is actually the biggest issue I face) . It's no real problem just adding "set isolation to dirty read;" to my SQL Commander session, but I mainly use the "Data" tab to browse table data...