Hi Bill,
Yes to the latest version, and not perfectly sure when the last
unload load command was. I am going to err on the side of safety and
say maybe NO. I plan on doing that tonight when everyone leaves. I
guess that is the best plan so far.
At 09:13 AM 1/6/2010, you wrote:
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
<<mailto:[email protected]>[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" <<mailto:[email protected]>[email protected]>
To: "RBASE-L Mailing List" <<mailto:[email protected]>[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" <<mailto:[email protected]>[email protected]>
>To: "RBASE-L Mailing List" <<mailto:[email protected]>[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?
>
