The VARBINARY workaround work perfectly, thank you very much for your help!
Sincerely,
Yves
Schroeder, Alexander a �crit :
Hello Yves,
the trace you did send to me tells now something more ...
The CMP engine of JBoss calls PreparedStatement.setObject(index, <some special object>, java.sql.types.JAVA_OBJECT) to serialize the Java object into the database. This actually is not really a good idea, as the JDBC driver does not really know and understand what now to
do with the object - it could possibly serialize it, and keep the fingers crossed about it ...
After looking into the JBoss code I could see the following interesting things:
* there was a time when JAVA_OBJECT in the CMP mapping did lead to converting the object into a byte array/byte array input stream by
serializing it, but this stuff is commented out. I encourage you to bother the JBoss people to tell what was the intention behind that and
whether they checked that this idea works ... as far as I know JDBC sees JAVA_OBJECT only as a good thing for SQL3-like UDT types.
* there is a workaround by using VARBINARY or BINARY as JDBC type in the configuration. In that case, JBoss will make a byte array of your object by serializing it (and even more interestingly, performing a special optimization for instances javax.ejb.EJBObject).
So try the mapping
<mapping> <java-type>java.lang.Object</java-type> <jdbc-type>VARBINARY</jdbc-type> <sql-type>LONG BYTE</sql-type> </mapping>
Regards
Alexander Schr�der SAP DB, SAP Labs Berlin
-- Yves Trudeau, Ph.D. Analyste en syst�mes T�treau Dumont Trudeau consultants inc.
-- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
