[RBASE-L] - RE: What's up with this?

[Dennis McGrath]

I've often found that as a system matures, you will find things that used to run fast that now take a relatively long time.

I make note of the slowdowns and attack each one as I find it.

 

The answer is always "How do I decrease the work required on the network?"

 

There are many things one can do to to do to improve perfomance, most of whicj have already been discussed.

 

Reports often require the most work to speed up.  Again, minimize the work the report must do over the network.

 

Building up report data with Temporary Tables is often the most productive.

If your report is doing lookups in the details, you will do better to build a table of the details, with the extra columns populated.

Make sure your scratch is set up so the Temp Tables are on the local drive.

You have to think carefully about what your report is required to do to acheive your goal.

Anything that happens repeatedly is a candidate for optimization.

It is far faster to update your Temp table with multi-table updates up front that to have oodles of individual lookups going on while the report runs.

And it is much easier to test and optimize these updates than it is to tweak the lookups in the report.

 

Dennis McGrath

 

 

---

From: rbase-l@rbase.com [mailto:[EMAIL PROTECTED] On Behalf Of Castanaro, Bob
Sent: Monday, July 10, 2006 1:54 PM
To: RBASE-L Mailing List
Subject: [RBASE-L] - RE: What's up with this?

Bob, et al,

I have a few legacy R:base apps that have some different flavors of R:base connected as I incrementally upgrade them.  Only on SOME apps do I get the slowdown (waiting for required resources) and usually this is when there are old DOS, RB65, and 7.1 apps hitting at the same time.  Otherwise, things seem to be OK on MS servers for low-moderate use.  It only seems to get hairy when trying to run large reports...

BC

---

From: rbase-l@rbase.com [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: Monday, July 10, 2006 2:35 PM
To: RBASE-L Mailing List
Subject: [RBASE-L] - RE: What's up with this?

I certainly am not a server expert, database expert or even a programming expert!

But I do know that there are probably millions of installations using Rbase, FoxPro, Access, Paradox, Pervasive(local  mode) and other non-client/server databases crunching away out there every day.  It is hard to imagine they are all having "show stopping" performance problems.

 

The company I mainly work for has several commercial applications they purchased that run on one or more of the above packages.  I have written a number of Rbase systems to integrate with the above as well and am working to replace some with Rbase apps. 

 

I have heard of the "speed" issue but I guess I am lucky enough not to have seen it.

Running a 2003 server, 1 gig connection between server and switch but 100mb from switch to the work stations.  Not a huge network, but more than 15 users and none of the database applications seem to have any problems, regardless of "brand".  Rbase is actually faster than the others!  I switched from a Novell system to Windows 2003 about 1 1/2 years ago and actually saw significant improvement, although I also upgraded the hardware at that time as well.

 

My point is, I would think that having just 2 PC's connected would not (should not) bring an application to a stand still?  There must be some settings somewhere that need tweaked.  I can see large number of users having significant impact, but small numbers I would not think one should see much issue. 

 

Again, I am one of the "lucky ones" that seems to not have speed issues!

 

-Bob

-------------- Original message --------------
From: "Dennis McGrath" <[EMAIL PROTECTED]>

Access will suffer the same problems on an MS server, since it is a file server db just like RBASE (I believe it was a rip off of RBASE to begin with!!!)

There is a considerable amount of server tuning instructions out there to

try to help alleviate the problem with file server dbs, but the MS security model generates lots of

network traffic due to the fact that it checks your access rights to each and every file

every time you access them over the network.

 

Novell of old had you log in , figured out your access rights, and screamed forward from there.

It's disk caching was awesome too. 

 

Better to avoid any MS caching of DB files!!!  Brain dead.

 

When we get to Client-Server, these issues will largely go away because all access to the db is by code running on the server and thus the db files are "local"

 

Dennis McGrath

 

 

 

 

---

From: rbase-l@rbase.com [mailto:[EMAIL PROTECTED] On Behalf Of Castanaro, Bob
Sent: Monday, July 10, 2006 12:55 PM
To: RBASE-L Mailing List
Subject: [RBASE-L] - RE: What's up with this?

 

Does anyone have any experience on this issue with Access?  OK, the DREADED Access.  Does Access have the same speed issues, or is there some trick they (MS) are not sharing that optimizes the MS servers?

 

For a small office, this will continue to be an issue and will be a problem for R:Base.  For a large installation, I'm sure the RB Client -Server will solve it.  Novell really blew it a few years back.  It was clean, stable and efficient.  R:base screamed on it.  They just had no clue how to market, and were way behind on a GUI interface.  Look how they bumbled Word Perfect, still the best word processor ever.

 

BC

---

From: rbase-l@rbase.com [mailto:[EMAIL PROTECTED] On Behalf Of Javier Valencia
Sent: Monday, July 10, 2006 1:41 PM
To: RBASE-L Mailing List
Subject: [RBASE-L] - RE: What's up with this?

 

Emmitt:

This is a nice checklist; however, as a way of background, my client has a Novell server and they were experiencing some delays (turned out to be a problem with R:Base, now fixed). We tried switching the client cards form auto to full duplex and the response dropped to a crawl, we set the cards back to auto and the performance improved dramatically. I am nor sure if this is typical but it would be wise to test it both ways and see if how performance is affected.

Javier,

 

Javier Valencia, PE

President

Valencia Technology Group, L.L.C.

14315 S. Twilight Ln, Suite #14

Olathe, Kansas 66062-4578

Office (913)829-0888

Fax (913)649-2904

Cell (913)915-3137

================================================

Attention:

The information contained in this message and or attachments is intended

only for the person or entity to which it is addressed and may contain

confidential and/or privileged material.  Any review, retransmission,

dissemination or other use of, or taking of any action in reliance upon,

this information by persons or entities other than the intended recipient

is prohibited. If you received this in error, please contact the sender and

delete the material from all system and destroy all copies.

======================================================

 

-----Original Message-----
From: rbase-l@rbase.com [mailto:[EMAIL PROTECTED]On Behalf Of Emmitt Dove
Sent: Monday, July 10, 2006 12:17 PM
To: RBASE-L Mailing List
Subject: [RBASE-L] - RE: What's up with this?

 

Lee,

The problem is a Microsoft thing.  Any time on an MS network with the database on an MS server, more than one user experiences slowdown.  To combat this, there are a few steps to take:

1. Use a gigabit link between all your machines. 
2. Use a switch downstream from the router.
3. Try to use hardware that supports full duplex.  Check your cards to see if they're operating full duplex, and if not (and set to AUTO), try forcing full duplex.
4. Use quality cables.
5. Make certain each user has scratch files set to their local drive.
6. Run with STATICDB ON.
7. Make certain the box holding the files is set to optimize for background services not applications.
8. Don't use the box holding the files for anything else.
9. Don't use peer-to-peer; install a domain controller (not on the file server).
10. Install R:Base locally on each client.
11. Run, don't walk, to 7.5, Windows not DOS.

Now, these are all in the nature of suggestions, but are things we've found improve the responsiveness.

Have you experienced the same types of difficulties when employing your applications in a network scenario?  What do the "big boy" clients do to avert this issue?
 
Thanks to all!
 
Lee
 

Emmitt Dove
Manager, DairyPak Business Systems
Blue Ridge Paper Products, Inc.
37 Sybil Ave
Branford, CT  06405
(203) 643-8022
[EMAIL PROTECTED]
[EMAIL PROTECTED]