jc_dissimilarity causing NonIdxScanException on 2nd attempt

JChem cartridge version: 5.3.0

 

Hi,

 

We’re seeing some strange behaviour when using jc_dissimilarity using any kind of
Similarity Metric.  

 

For example:

 

SELECT key,id,smiles,
jc_dissimilarity(smiles,'Cn1cnc2n(C)c(=O)n(C)c(=O)c12','dissimilarityMetric:NORMALIZED_EUCLIDEAN')
as similarity

FROM
table Where id = 'XXXXXXX'

 

We can execute the query fine the
first time giving a row with a similarity value. When we run the identical
query again we get an error.  Normally this is some sort of NumericOverflow error from the
cartridge:

 chemaxon.jchem.cartridge.oresident.nonidxscan.NonIdxScanException: Numeric Overflow

 

After this error we find we cannot properly use JChem and have to disconnect the session.  We are then able to repeat this behaviour in the new session.

 

We've tried using different SMILES for the input and for the db table data, but with no change in behaviour.   

 

Any ideas?

 

Thanks

Hi,

I haven't been able to reproduce the problem using a simple test case.

Can the problem be reproduced, by simply

1. starting a new database session and


2. consecutively executing the following query twice:
   SELECT id, smiles, jc_dissimilarity(smiles,'Cn1cnc2n(C)c(=O)n(C)c(=O)c12','dissimilarityMetric:NORMALIZED_EUCLIDEAN') as similarityFROM table Where id = 'XXXXXXX'
   

?

Is the problem reproducible with any query-target pair or with just one specific combination? If the problem is query-target specific, what similarity value is returned for the first (successful) time?

Which Oracle version is it?

Please, could you post the corresponding Java stack trace found in the Oracle session trace (under the udump directory in 10g and under the diag directory in 11g), as well as the corresponding Java stack trace from the JChem Server's log, if available?

Thanks

Peter

Hi Peter, on further investigation this seems to be a red herring.  There were no errors being logged in Oracle so I tried running the query in a different SQL client (sqlplus instead of SQL Developer) and the query could be run repeatedly.  Why SQL Developer was throwing a JChem exception is a mystery, I think this must be a bug in the client software.

 

Apologies for the false alarm.

 

Thank you for the feedback.

Is it not that the locale of the client is different from the server's NLS setting...or something similar?

Thanks

Peter