** ** Isabel,
I have never used the in place feature for importing a form, but what is happening at the background, I believe, is that the underlying database table is being copied without the column and once copy has been created, the original table is dropped and the copy renamed to take place of the original table (this is what happens when you delete a field manually). It may be the case, that for every single field which has been removed the in place import goes through this routine. I would suggest switching on SQL logging on the server (if possible) and checking what is happening. You can find out which statement is causing the timeout. Alternatively, you can log in directly to the database and check the underlying table (Txxx) corresponding to the form to see what its status is. You can check its number of columns and also if there is any table with similar name, i.e. something like TxxxTMP. Hope this will give you some hints on where your import currently is. Regards Jiri Pospisil Technology Support Systems ▪T▪ ▪ ▪Mobile UK▪ -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Ross, Isabel Sent: 28 December 2006 11:48 To: arslist@arslist.org Subject: Import In Place - Timeout During Database Update Hello I’m in the middle of a change to our live system and looking for some reassurance…. Our main form is sprt_Service_Request (it was originally part of the CRM application, and for that reason among others, has more fields in it than is healthy). The form had 789 fields in it, of which 661 were database fields. A nightmare to maintain, and we were running into performance issues. On the dev and training system I’ve reduced this to 386 fields of which 296 are database fields. I copied the form from dev to training using “Import in Place” and it took around 8 hours to complete. As the work was in progress, any queries on sprt_Service_Request would work, but would give an error such as: ARERR [552] Failure during SQL operation to the database : ORA-00904: "C600000050": invalid identifier i.e. referring to one of the fields which had been deleted. The next time the query ran, the error would be about a different field, until finally it completed successfully. In the live system there is a lot more data, and we expected it to take longer. However for 2-3 hours this morning the error related to one single field and it has only just changed. Also I got an error on live that I did not get on the training system: “ARERR 92 Timeout during database update. The operation has been accepted by the server and will usually complete successfully” Our users have very reluctantly agreed to 24 hours of downtime. This means that if the import in place has not completed in the next 2 hours, we are going to have to think about restoring from a database backup and being stuck indefinitely with this oversized table. - is there any way of estimating how much longer this has to go before it completes? If I could say it was definitely going to complete in say 4 hours, then I could possibly negotiate some extra downtime… (in the meantime the system is in admin only mode and escalations have been disabled) We’re on AR System 6.03.00 patch 18 Sun Solaris 8 Oracle 9 Thanks Isabel Isabel Ross Glasgow City Council Phone: 0141 418 1484 E-mail: [EMAIL PROTECTED] www.glasgow.gov.uk Support Scotland's Bid to host the 2014 Commonwealth Games in Glasgow - visit www.glasgow2014.com ---------------------------------------------------------------------------- Disclaimer: This message is intended only for use of the addressee. If this message was sent to you in error, please notify the sender and delete this message. Glasgow City Council cannot accept responsibility for viruses, so please scan attachments. Views expressed in this message do not necessarily reflect those of the Council who will not necessarily be bound by its contents. ---------------------------------------------------------------------------- __20060125_______________________This posting was submitted with HTML in it___ __20060125_______________________This posting was submitted with HTML in it___ NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information.
