We are currently using Instant JChem 5.9.3 on a Oracle database with the JChem cartridge and have noticed the following issue:
The table contains some fields which are automtaically populated from a trigger.
When adding a new row to the table from Instant JChem, the users enters several pieces of information including a dummy structure (because the structure column is mandatory).
Using several trigger(s), other information is added to the table, and the correct structure is populated via a lookup in a different table.
But in Instant JChem the user only sees a blank row, and the new added data is only displayed once a query is run.
When the database trigger is disabled, the data is displayed directly into Instant JChem. But we don't really want to do this, as we want to automatically retrieve data from the other tables.
Can you reproduce the problem ?
I should be able to try and replicate this issue in essence.
I have an IJC/CART 5.10 environment ready to go.
I would just need to create some simple test trigger which attempt to do somthing similar to yours.
If I cannot replicate it then I will need to create specific 5.9.3 env and so on.
Does this initial test sound reasonable ?
Yes, this seems absolutely fine
Just a few more question please :
Which table type do you use, presumably it either : jchem + idx or std + idx ?
Which Oracle Index User display this: 'jchem', 'owner' or 'user' (or perhaps all do).
You imply that a dummy structure (drawn in Marvin) is overridden in the bespoke structure tables trigger by a structure obtained from another table source - could you say the format of this structure please - SMILES?
How do you join to the other table - some VARCHAR2 identifier ?
Many thanks for the info,
The structure is stored in smiles in a reference table A with an ID
The data is entered in table B, including the ID field, the trigger retrieves teh Smiles from table A based on the ID column
The tables are standard Oracle table with a cartidge index.
I can share my table definition and trigger with you if you send me your email address, this might make it easier ?
Please share what you can please to speed up my turnaround : dbutler at chemaxon.com
Thanks for this information - I can confirm your observation and will report this as a bug to the team.
I think we have reached a happy conclusion for this reported issue and so will close it.
Some further information :
This was essentially fixed by remove one of trigger that access a sequence object that is also in use by the INSERT statement that caused the trigger to fire. This in fact did work (the trigger over-wrote as expected) but it caused a temporary internal conflict with the current viewed record set.