I can reproduce the problem. We'll look into fixing it soon. For now, a work-around is to go into Global Preferences -> Data Type Control Controls and under CLOB, check "Read contents when table is first loaded" and choose "all". This makes the data available instead of the placeholder right away (it's expensive to load all CLOB records all of the time - so that is why it is not the default). Perhaps this will keep you going until we get a proper fix.
Rob
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I see the problem. Apparently Derby now disallows further access to the Java Clob once the transation is committed. When using placeholder (<clob>) for performance, we store the Clob that the driver gives in a ClobDescriptor for later access. We then access it outside of the transaction in which it was created yielding:
java.sql.SQLException: You cannot invoke other java.sql.Clob/java.sql.Blob methods after calling the free() method or after the Blob/Clob's transaction has been committed or rolled back.
So, an alternative work-around is to turn off auto-commit. The <Clob> placeholder can then be clicked on and it will cause the data to be loaded. I guess this solved a caching problem for Derby folks, but it kind of hoses us :)
I suppose the Derby plugin could provide a custom data type component for Clobs, overriding the placeholder feature.
Rob
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I started to provide a custom type implementation for Derby for CLOBs, however, our type framework doesn't handle well the use of different type implementations for different session types for the same type. That means that use of the Derby plugin which overrides the CLOB type, would cause sessions to other databases (Oracle, PostgreSQL, MySQL) to also use that custom type. Some work is needed in the framework to allow plugins to override types only for their sessions and that could affect how other plugins are currently using this framework for non-standard types. This coupled with the proximity of the release date and the availability of work-around (disabling auto-commit), leads me to conclude that this work should be done in the 2.7 dev cycle. I wish I had known about the Derby problem sooner.
Rob
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=1287991
Originator: NO
James,
I can reproduce the problem. We'll look into fixing it soon. For now, a work-around is to go into Global Preferences -> Data Type Control Controls and under CLOB, check "Read contents when table is first loaded" and choose "all". This makes the data available instead of the placeholder right away (it's expensive to load all CLOB records all of the time - so that is why it is not the default). Perhaps this will keep you going until we get a proper fix.
Rob
Logged In: YES
user_id=1287991
Originator: NO
I see the problem. Apparently Derby now disallows further access to the Java Clob once the transation is committed. When using placeholder (<clob>) for performance, we store the Clob that the driver gives in a ClobDescriptor for later access. We then access it outside of the transaction in which it was created yielding:
java.sql.SQLException: You cannot invoke other java.sql.Clob/java.sql.Blob methods after calling the free() method or after the Blob/Clob's transaction has been committed or rolled back.
So, an alternative work-around is to turn off auto-commit. The <Clob> placeholder can then be clicked on and it will cause the data to be loaded. I guess this solved a caching problem for Derby folks, but it kind of hoses us :)
I suppose the Derby plugin could provide a custom data type component for Clobs, overriding the placeholder feature.
Rob
Logged In: YES
user_id=1287991
Originator: NO
James,
I started to provide a custom type implementation for Derby for CLOBs, however, our type framework doesn't handle well the use of different type implementations for different session types for the same type. That means that use of the Derby plugin which overrides the CLOB type, would cause sessions to other databases (Oracle, PostgreSQL, MySQL) to also use that custom type. Some work is needed in the framework to allow plugins to override types only for their sessions and that could affect how other plugins are currently using this framework for non-standard types. This coupled with the proximity of the release date and the availability of work-around (disabling auto-commit), leads me to conclude that this work should be done in the 2.7 dev cycle. I wish I had known about the Derby problem sooner.
Rob
Logged In: YES
user_id=1287991
Originator: NO
This has been fixed in the trunk - will go out in the next snapshot and release 2.7.
Rob