large table queries

Hi,


I have a table with slightly more than 10 million compounds. When I run a search, JChemSearch seems to run forever. It keeps refreshing new pages and maintains the "Collecting Fingerprints" page forever. Is there a work around? Can I create the do the fingerprint collection outside of the web UI and use it for my web searches in the future?





Also, when I do a jcman -t , it reports the count incorrectly as well. All tables with count less than 10 million is reported correct. However for this table with more than 10 million compounds, it truncates the first digit and reports the count.





Renju

Hi,

Quote:

I have a table with slightly more than 10 million compounds. When I run a search, JChemSearch seems to run forever. It keeps refreshing new pages and maintains the "Collecting Fingerprints" page forever.

Could you please provide more detail for the bug report ?


Which JChem version are you using ?


Are you getting the problem in the JSP example application we provide in the package (same as http://www.chemaxon.com/jchem/examples/jsp1_x/index.jsp )?


What query options did you use when getting this problem ?


Was the structure cache turned on ?

Quote:

Can I create the do the fingerprint collection outside of the web UI and use it for my web searches in the future?

No, but it should not take long under normal circumstances.

Quote:

Also, when I do a jcman -t , it reports the count incorrectly as well. All tables with count less than 10 million is reported correct. However for this table with more than 10 million compounds, it truncates the first digit and reports the count.

Fixed, it will display fine up to 10 digits from the next release (JChem 3.2).





Best regards,





Szilard

I am using JChem version 3.0.5. even with the structure cache turned on and when I use the package interface ../jsp1_x/.. it still keeps running. Instead of 'collecting fingerprints', it says 'collecting id numbers' when I select the virtual library and run the index file

Quote:

when I select the virtual library and run the index file

Sorry, I'm not sure I understand this part.


Could you be more specific ?


(Maybe you are thinking about the opening page in the JSP example where all structures are displayed without running a query ?)





Could you check what is the CPU utilization of the server during the mentioned period


(does it seem to be working on 100% CPU or is it idle ) ?





In any case I suggest upgrading to the latest version (3.1.7.1), 3.0.5 is quite old, there has been numerous fixes and improvements since then.





Szilard

I should have clarified; 'Collecting fingerprints' message comes when I run a query and 'Collecting id numbers' message comes when I am loading the index file. Either ways, it seems to be running forever. I can't see the server CPU utilization for the task, since I am running the search from a client PC.


The reason why I hesitate to switch to a new version is that, all the JSP pages which I have written then starts giving me error messages after I regenerate the tables. Some say 'deprecated API' or some say that this version does not support so-and-so properties etc.


If you could probably post a list of changes that you make to the jsp1_x package and the source code (*.jsp) that you change, it would be very helpful. That way a person like me who programs using your APIs would be able to go back and make those changes when updating the version


Thanks!

Quote:

The reason why I hesitate to switch to a new version is that, all the JSP pages which I have written then starts giving me error messages after I regenerate the tables. Some say 'deprecated API'

True, deprecation is sometimes necessary in all APIs.


However deprecated things should work after a version change.


It is just a warning, that you should switch to the new methods, because this will be removed in the future.


In the API documentation


(http://www.chemaxon.com/jchem/doc/api/)


we always state what alternatives we offer for deprecated methods or classes.





After a sufficiently long time we delete the deprecated methods, so I recommend upgrading from 3.0.x to 3.1.x before 3.2 comes out - the transition will be smoother.

Quote:

or some say that this version does not support so-and-so properties etc.

I do not know what are you thinking about.


Could you give us an example ?





Maybe you just forgot something during the upgrade process last time ?


Please also see this topic on how to upgrade:


http://www.chemaxon.com/forum/viewpost2807.html#2807





In general we at ChemAxon take care that our newer versions are backward compatible.


Our users in general upgrade frequently without problems.





Szilard