Mark, If it gets slower the longer R:BASE runs, I would suspect the R:BASE application first. Are resources being released as early as they can be? Clearing variables, especially any that hold varbits or varchars, dropping cursors, etc? Are there any recursive loops, for example in a menu system, when a file that finishes runs the main menu file again?
On Fri, May 22, 2009 at 8:37 AM, MDRD <[email protected]> wrote: > HI John > > I do not have a way to do that but their tech is a MS certified guy and is > running some network test for me. > He is also good friends with the office. > > They tried shutting down AV, Spyware, Google Indexing and other things like > that. They have 1 Gig networks cards > and switches. > > I am almost done making 3 more EEPs to send them to test and see which > works better. One EEP is the same code > but has Pause 3 commands every so often so we can see where things slow > down. > > Thanks > Marc > > > *From:* John Engwer <[email protected]> > *Sent:* Friday, May 22, 2009 7:06 AM > *To:* RBASE-L Mailing List <[email protected]> > *Subject:* [RBASE-L] - Re: Workstation speed > > Marc, Do you have access to the PC in question through RDP or some other > program? If so, I would pull up MS Task Manager and look at the CPU usage > and memory usage when the application is running fast and when the > application is running slow. This should tell you if you have a problem in > either area. If you don’t have access you will need to have the operator > collect the data for you. Not long ago, I had a client that had a weather > radar program that continually refreshed a map as weather conditions > changed. If there were storms in the area it would suck-up all of the PCs > resources and my application would run slow. By looking at Task Manager you > could see the process servicing the weather program using more and more of > the resources. > > > > John > > > > *From:* [email protected] [mailto:[email protected]] *On Behalf Of *MDRD > *Sent:* Friday, May 22, 2009 7:46 AM > *To:* RBASE-L Mailing List > *Subject:* [RBASE-L] - Re: Workstation speed > > > > Buddy, George and all > > > > > > This EEP is used about 60-100x a day, Restarting RBase fixes this. > > > > Dropping the table and Projecting the way I was doing did not make any > difference. Therefore it seems either a Disc frees up > > something and maybe forces some buffer cache to get cleared on > Workstations. I have never heard of this from the local computer. > > > > So, I think I will send them a update with several buttons using these > different versions with Pause 3 and 4 counting up from 1 to 10 > > so they can tell me where things bog down. > > > > One of the big offices that had the problem is going to be a training > office for that Other program! I would love to get this speed thing > > nailed down so they can compare my app when it is running at top speed. > > > > These offices are speed nuts, they do repetitive tasks entering invoices > one after another. Some run this EEP from the local computer > > others the workstation. > > > > I will post my findings, > > > > my .0000001 cents is these workstations have some sort of buffer cache > thing that gets filled up, like cleaning out your temp internet files > > > > Thanks for all the help, now I have several ways to test. > > Marc > > > > > > > > > > *From:* Walker, Buddy <[email protected]> > > *Sent:* Thursday, May 21, 2009 6:41 PM > > *To:* RBASE-L Mailing List <[email protected]> > > *Subject:* [RBASE-L] - Re: Workstation speed > > > > Marc > > If you are deleting the rows instead of dropping the table I think it get > slower. I use temp tables and views and I drop and recreate them each time > the criteria changes to populate the view or table. Since I’ve been doing > that I very rarely have problems with speed. > > > > Buddy > > > > > > *From:* [email protected] [mailto:[email protected]] *On Behalf Of *MDRD > *Sent:* Thursday, May 21, 2009 7:09 PM > *To:* RBASE-L Mailing List > *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 <[email protected]> > > *Sent:* Thursday, May 21, 2009 5:44 PM > > *To:* RBASE-L Mailing List <[email protected]> > > *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 <[email protected]> > > *Sent:* Thursday, May 21, 2009 4:56 PM > > *To:* RBASE-L Mailing List <[email protected]> > > *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 <[email protected]> > > *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 > > >
