Marc,
Just a shot in the dark. How many times a day is this process imitated? Then,
how often is the database Packed?
The space should still exist which was used by the dropped tables and if it
does, the increased overhead may work to increase the slowing of processing.
I watch the database size increase dramatically when I test certain code while
in development.
Just a thought to add to Buddy's reply.
My 1 1/2 c worth,
George
----- Original Message -----
From: MDRD
To: RBASE-L Mailing List
Sent: Thursday, May 21, 2009 6:09 PM
Subject: [RBASE-L] - Re: Workstation speed
Buddy
So, you think
Drop table
Project where Count=0
Insert
will be faster than
Drop Table
Project
Why would this get slower as the day goes on?
That seems like something is not getting refreshed.
Funny how only 3-5 rows can get slower no matter what method I use.
Thanks
Marc
From: Walker, Buddy
Sent: Thursday, May 21, 2009 5:44 PM
To: RBASE-L Mailing List
Subject: [RBASE-L] - Re: Workstation speed
Marc
That is why I’m saying drop the temp table and then recreate each time you
want to add different rows instead of del rows ..
Projecting the table where count = 0 creates the table without any rows. It
is a lot faster then trying to create the table and add the rows at the same
time. I believe doing an insert instead of a project or append seems faster.
Buddy
From: [email protected] [mailto:[email protected]] On Behalf Of MDRD
Sent: Thursday, May 21, 2009 6:29 PM
To: RBASE-L Mailing List
Subject: [RBASE-L] - Re: Workstation speed
Buddy
My code is fast at the start of the day, the longer they use my app the
slower this gets
the rest of my app stays fast. Restarting Rbase / my app makes it faster
again
Not to sound dense but I will anyway... I do not under the Where Count = 0 ?
To me it seems like the Temp table bogs down the longer you use it and is not
cleared from
memory or some other tech thingy.
Marc
From: Walker, Buddy
Sent: Thursday, May 21, 2009 4:56 PM
To: RBASE-L Mailing List
Subject: [RBASE-L] - Re: Workstation speed
Marc
If your form is based on the temp table and you are projecting only the
rows you want, then I wouldn’t use the where clause on the EDIT using… I
wouldn’t delete rows from the table either I would drop the table and recreate
it.
One thing you might want to try is
DROP TABLE tran_spd
PROJECT TEMP TABLE tran_spd FROM tran_hist USING * WHERE COUNT = 0
INSERT INTO tran_spd (list only the columns you actually need) +
SELECT the same list of columns in table FROM +
Tran_hist WHERE custnum = .vcust AND …….
EDIT USI spdyov2
No where clause should be necessary since you already filtered the table
with the project and insert where clause.
Buddy
From: [email protected] [mailto:[email protected]] On Behalf Of MDRD
Sent: Thursday, May 21, 2009 5:21 PM
To: RBASE-L Mailing List
Subject: [RBASE-L] - Re: Workstation speed
Bob and Karen
It seems when I first went from 6.5 to 7.5 I used a regular table with
Indexes.
But I switched to Temp tables thinking it would be safer is 2 workstations
were doing the same EEP.
It has been a long time and in the server you can not tell any difference.
There are only 3-5 rows each time.
These offices waited for several updates of mine so I can't be sure which of
my "improvements" caused this <g>
Scratch is Local TMP
I have tried Drop and Project but they say it is still slow
DROP TABLE tran_spd
PROJECT TEMP tran_spd FROM tran_hist USING * +
WHERE custnum = .vcust AND tr_type = 1 AND tr_date = .vmaxdate
EDIT USING spdyov2 +
WHERE tr_type = 1 AND custnum = .vcust CAPTION .vcap
I need to find 2 slow computers to network to make it easier to test this
Thanks
Marc
From: [email protected]
Sent: Thursday, May 21, 2009 3:10 PM
To: RBASE-L Mailing List
Subject: [RBASE-L] - Re: Workstation speed
Marc,
I would not use Delete Rows from a temp table when wanting to remove all
rows. This is much slower
if there are any number of rows to delete.
Instead try,
Drop table Tran_spd
Project temp Tran_Spd from (Permanent empty table name of same column
structure) using all
or
If Speedov has the same column names, skip the insert and
Project temp Tran_Spd from Speedov using (column list) where......
This may prove even faster yet. However, note that a lock will be placed on
Speedov if you
use the project from it. Otherwise project using Where limit = 0 and then
use the Insert if a lock
on the table would be problematic.
You do not say how many records are being inserted at a time. You do not
show building an
index on your temp table. I normally do not use indexes on temp tables
unless there is a lot of
data and of a type that an index would help with. If you have indexes and
are using the
Delete Rows command, that will definitely be slower as it has to update all
the indexes as well.
As Karen stated, make sure your temp settings are local.
-Bob
----- Original Message -----
From: [email protected]
To: "RBASE-L Mailing List" <[email protected]>
Sent: Thursday, May 21, 2009 2:53:10 PM GMT -06:00 US/Canada Central
Subject: [RBASE-L] - Re: Workstation speed
Marc: Have you tried using a permanent table in 7.5 to see if it's faster
than using the temp table? And if you're using temp tables, make sure your
scratch setting is to a local drive (like SET SCRATCH C:\TEMP) so that temp
table information is kept local rather than traveling through the network.
Karen
This is the second office that has brought up the issue of Rbase getting
slower as the day wears on.
This tech is a certified network guy so I assume the network is OK, new
computers 1 gig switches ...
My old code used a regular table and I would just delete rows .....but I
never heard a complaint on
the speed
-- tran_spd is a temp table that is created on start of the main menu
DELETE ROWS FROM tran_spd
-- APPEND .... using append instead of insert does not seem to make any
difference
INSERT +
INTO tran_spd (custnum,date_con,tr_date,tr_type,ch_code,ch_price,+
ptest,dig_ch,memo,treat_dr,inscomp,inshold,modf1,modf2,modf3,+
modf4 ) SELECT custnum,date_con,tr_date,tr_type,ch_code,ch_price,+
ptest, dig_ch,memo,treat_dr,inscomp,inshold,modf1,modf2,modf3,+
modf4 FROM speedov WHERE custnum = .vaptcust
EDIT USING spdyov2 +
WHERE tr_type = 1 AND custnum = .vcust CAPTION .vcap
Then then click a button to Save or append these charges to another table
then
go back to this same EEP again.
Even if I drop Temp tab and Project Temp tab is not faster
I think is it my program logic not 7.5, but my old permanent table in 6.5
was faster than the
temp table in 7.5
Why would using Temp table be slower?
Marc
