Hi Ocke, > That would be great. But an issue where you attach the bugdoc would > even be better :-)
I got the following mail from our JDBC driver developer, which makes me think it's not an issue. What do you think? --- snip --- Working with LOB columns is extremely difficult due to many restrictions on when the data can or must be accessed. Autocommit makes it very difficult to handle LOB locators. I do not recommend enabling locators during autocommit, especially with a cursor mode of 'multi'. Simulating autocommit to support multiple open cursors (which Ingres does not support) results in full transaction commits being issued by the driver. A full commit invalidates a LOB locator, which is probably the cause of your problems. With locators disabled, the application must process the streamed LOB data. This restricts what actions may be taken on the connection. The application is attempting to issue a new query when there is LOB data still to be processed. The driver protects the data stream with locks, which is causing a dead-lock in the application. Most generic applications are not disciplined enough to follow JDBC portability guidelines of reading all columns in order and only once when processing result-sets. My suggestion is that you do not enable lob locators (use default settings), but that you enable the caching of LOB data. This will avoid the transaction conflicts with locators and restrictions on processing LOB data streams. The downside is that LOB data will need to fit in memory. Please review the BLOB Column Handling section of the JDBC chapter in the 2006r3 Connectivity Guide. --- snip --- The suggestion to enable the caching of LOB data works for me. Maybe this is what databases which run out of the box with OO do by default. While doing more tests of the driver unfortunately I discovered the following two problems: When I click the save button in the table design view for a new table without having set a primary key beforehand a dialog appears which allows me to let OO create a additional column 'ID' as primary key. That's fine so far. When I click the 'Yes' Button in the dialog the create table statement is executed correctly, but OO doesn't recognize the new table until the tables are refreshed manually by clicking 'View -> Refresh Tables'. In table design view you may again click the save button as OO doesn't recognize that the table is created successfully. Clicking the button again produces an SQL error as the table already exists. Similar thing happens when I use the table wizard to create a table. Clicking finish executes the create table statement correctly, but the table isn't displayed in the list of tables and the wizard doesn't close itself. Clicking the finish button again produces an SQL error as the table already exists. Any ideas what might be the root cause? I did a bit code reviewing but found nothing suspicious so far. Do you know what queries are usually executed after saving a table? Possibly there is one that doesn't work with Ingres in these situations. Best regards, Micha --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
