jc_insert problem, jchem3.2

java.lang.NumberFormatException: null


at java.lang.Integer.parseInt(Integer.java:436)


at java.lang.Integer.parseInt(Integer.java:518)


at chemaxon.jchem.cartridge.JcMetaDataFunctions.getTableType(JcMetaDataFunctions.java:244)


at chemaxon.jchem.cartridge.JCartDml.insertMolMulti(JCartDml.java:611)


at chemaxon.jchem.cartridge.JCartDml.insertMol(JCartDml.java:540)


at chemaxon.jchem.cartridge.JCartDml.insertMol(JCartDml.java:316)





Can anyone please help with the following error message?


I seem to get this error every time I attempt a jc_insert statement using version jchem 3.2 (Tomcat 5.0.28 Oracle 10.2, red hat EL 3).





The table to be inserted to was created directly in 3.2 (not regenerated) starts off empty and does have a jc index on the cd_smiles column.





thanks for your help,


Daniel.

simple SMILES below will cause this exception to be thrown...





declare


v_cd_id CD_ID_ARRAY := NULL;


begin


v_cd_id := Jc_Insert ('C','temp','JCHEMPROPERTIES','false','false','');


commit;


exception when others then raise;


dbms_output.put_line (sqlerrm);


end;


/

racle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod


PL/SQL Release 10.2.0.1.0 - Production


CORE 10.2.0.1.0 Production


TNS for Linux: Version 10.2.0.1.0 - Production


NLSRTL Version 10.2.0.1.0 - Production


NLSRTL Version 10.2.0.1.0 - Production


JChem version in the database: 3.2


JChem version in the Tomcat server: 3.2


java.vm.version: 1.4.2_11-b06


java.vm.vendor: Sun Microsystems Inc.


Apache Tomcat/5.0.28


Major JDBC version in Tomcat: 1


Minor JDBC version in Tomcat: 0

hope this helps

Quote:

The table to be inserted to was created directly in 3.2 (not regenerated) starts off empty and does have a jc index on the cd_smiles column.

How did you create the table? I was unable to reproduce this problem either by creating a table through JChemManager or through the JChemCartridge API. (I have realized just now that it was a big conceptual mistake to implement the PL/SQL stuff for managing JChem tables. JChem tables are by definition created and managed using JChem Base tools or the JChem Base Java API. But this is what happens when one is all too lenient on user requests. :-) )





Anyway, there is a chance that regeneration leaves you with a table, on which jc_insert can fall over and this possibility should be removed. The fix will be available in the next JChem release.





Regards


Peter

And thanks for reporting the problem.





Peter

Hi Peter,





The problem seems to exist for both tables that have been re-generated and those that are new i.e. created directly by v3.2 jcman for all smiles.


The structures (desc) of each are quite normal I guess, both have additional number fields and the error suggests it could be related to these additional columns?





Would you suggest that I roll back to 3.1.7 or 3.1.6 for now?


This new ddl functionality should be really useful so I think you were right to include it, however the user in question who asked for this was me - so sorry to cause you all this trouble! Any ideas when this next patch is likely to surface? I'm not sure my java stored procedure version of jchem ddl is compatible with my 10g jvm and so could hit issues with it (i.e. if I have to rollback version and use it).





Cheers + all the best,





Daniel.

Hi Daniel,





The problem is that the JChem table does not have a table type assigned to it and one of the jcart routines was not equipped to handle such cases. (Table types have been introduced with JChem 3.2.)





The fix will be in JChem 3.2.1 which is planned to be released next week.





Cheers,


Peter

Hi Peter,





Getting this fix next week will be fine.


Thanks for the great support as usual.





Cheers,


Daniel.

JChem 3.2.1 is out with the promised fix.