Dan, Are you running the latest version of v8 Turbo?
Did you rebuild the database completely since V7.6, with OUTPUT filename; UNLOAD ALL; RUN filename, etc? Bill On Wed, Jan 6, 2010 at 9:10 AM, Dan <[email protected]> wrote: > Yes, I can browse where <> 0 and get nearly instantaneous results, > > select count invcur from ardetail where invcur <> 0 is immediate > > that is how I determined that about one update per 1.5 seconds is what is > happening. > > > > At 08:30 AM 1/6/2010, you wrote: > > hmm.. something is definitely an issue. Good news is that once the >> >> source is found, you should have satisfactory performance. >> >> >> >> Using ver. 8, I just tested... >> >> >> >> R>update testtable set location = '99' >> Columns have been updated in 100908 row(s) in testtable >> >> the process took just under 7 seconds, running over a 100mb network, >> >> database located on a server and three sessions attached. >> >> >> >> If you do a .. >> >> >> >> Select invcur,paycur from ardetail or >> >> Browse invcur,paycur from ardetail >> >> >> >> do the results show immediately? >> >> >> >> -Bob >> >> >> >> >> ----- Original Message ----- >> From: "Dan" <[email protected]> >> To: "RBASE-L Mailing List" <[email protected]> >> Sent: Wednesday, January 6, 2010 7:18:45 AM GMT -06:00 US/Canada Central >> Subject: [RBASE-L] - Re: Update command taking forever >> >> >> Bob, >> Thanks for responding. >> 1. using latest version dated last week >> 2. QUALCOLS is set to 10 already >> >> Have not unloaded and reloaded in the last week, but that table never >> gets deletes, but that still is something to try, can't do it now >> till everyone goes home tonight and I stay late. I could try it on >> a backup database and see. I guess that is my next step. >> >> 3. Using the update on just one column where there is a non zero, I >> am getting one row updated per second and a half. So the command is >> working, but will take a long time. >> >> Dan >> >> At 08:08 AM 1/6/2010, you wrote: >> >> >Dan, >> > >> >Indexes are only meant to increase the speed of identifying rows, >> >not the actual update. >> > >> >So you definitely do not want to add indexes to the columns you are >> >updating. That would >> > >> >actually slow down the process as you would now be updating the >> >indexes as well as the >> > >> >data. >> > >> > >> > >> >Updating 100,000 rows should not take too long, so something is >> >certainly askew. >> > >> > >> > >> >So some things to check... >> > >> > >> > >> >Look at your setting for QualCols >> > >> > >> > >> >R:>sho qualcols >> > >> >QUALCOLS is set to 10 >> > >> > >> > >> >If it is not set to 10, then set it. This can make a significant >> difference. >> > >> > >> > >> >Unload and Reload the database if you have not already done so. If >> >there have >> > >> >been much row deleting etc. sometimes the database files need >> >packed. Although >> > >> >I am hard pressed to think this would cause an hours long update. >> > >> > >> > >> >Try updating just one column at a time and see if the time is >> >different and report back. >> > >> > >> > >> >Make sure you are running the latest version. There were changes >> >made that directly >> > >> >effected speed in certain cases. >> > >> > >> > >> >-Bob >> > >> > >> >----- Original Message ----- >> >From: "Dan" <[email protected]> >> >To: "RBASE-L Mailing List" <[email protected]> >> >Sent: Wednesday, January 6, 2010 6:25:51 AM GMT -06:00 US/Canada Central >> >Subject: [RBASE-L] - Update command taking forever >> > >> > >> > >> > >> >Hi, >> > We have finally made the conversion to Turbo 8, and am having >> >troubles with my month end financial processes. I assumed it was >> >index problems and made sure there are indexes. >> > >> >Update ardetail set invcur = 0, paycur = 0 >> > >> >used to take seconds in 7.5 26 hours and counting in turbo >> > >> >in 7.5 neither invcur nor paycur had indexes. >> >I added them now, and still no increase in speed. So then I >> >thought, ok with the new indexes, lets key just off those.. >> > >> >Update ardetail set invcur = 0 where invcur <> 0 (excluding 95000 >> >rows) only 1300 should now be looked at, and this still takes forever. >> > >> >Where should I look next? >> > >> >> > >
