William, this looks like a locking issue. Perhaps some other threads has also updated this row but hasn't commited yet. There is a parameter you can set in ar.conf Next-ID-Commit: T When the system generates the next ID number for a record in the database, it performs a new commit transaction if this parameter is set to T (true). If the parameter is set to F (false), the transaction to generate the next ID is included as part of the create entry transaction. Set the value to T to increase efficiency and for debugging. The default is F. This option does not work with Informix databases. HTH Kind Regards Conny
________________________________ Von: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] Im Auftrag von William Rentfrow Gesendet: Mittwoch, 4. November 2009 19:39 An: arslist@ARSLIST.ORG Betreff: Looooooooooong update times on ARSCHEMA ** Listers... I was helping a person who contacted me look at a performance problem. I do not have access to the system. It appears the update to ARSCHEMA that is called by the CE API call is taking forever for just ONE record. In other words when this executes: UPDATE arschema SET nextId = nextId + 1 WHERE schemaId = xxx ...it works fine for all but 1 row. Most rows complete in 0.01 seconds or less. The troublesome row update can take 90 seconds or more. I've never seen that. Has anyone else? I thinking rebuilding the indexes on that table is the first thing to try. William Rentfrow Principal Consultant, StrataCom Inc. wrentf...@stratacominc.com Corporate Website, www.stratacominc.com <http://www.stratacominc.com/> Blog, www.williamrentfrow.com <http://www.williamrentfrow.com/> 715-410-8156 C _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"
