From: "Ben Petersen" <[EMAIL PROTECTED]>
Reply-To: [email protected]
To: [email protected] (RBASE-L Mailing List)
Subject: [RBASE-L] - RE: What's up with this?
Date: Tue, 11 Jul 2006 07:47:20 -0700
Bob,
I've run into to this at three customer sites. Two are running windows
server
(2003?) software. I work remotely and do not have the expertise I need to
tweak server settings. Interestingly, one site used a computer tech for
years
who I felt was pretty good. After working with him for a while one day he
concluded it was a file locking/sharing issue between Windows Server and
R:Base and there was nothing we could do. He went on to work as a
network administrator at the local college. The tech that replaced him at
the
customer site walked in and solved the problem w/o fanfare. All he did was
turn "opportunistic file locking" ON and excluded R:Base from virus
checking. The customer said it was a "day and night" difference. I should
note that no more than three people would access the database at one time,
and as you said, it is the second user that gets awful, awful performance.
It
is not a matter of bandwidth or server horsepower.
Another site with the same app and same windows server platform was
experiencing what you are also. When I passed the fix on to their tech
nothing happened. He was only insistent there was nothing "wrong" with the
network. Communication there is poor and I have not been able to learn
more.
At the third site they are running XP Pro Peer to Peer with only two
computers accessing the same app as above. Same symptoms. I have not
found a file locking setting for XP, but have not taken much time at all to
scope out the problem there either.
I'd appreciate your posting back whatever you learn about this. It's been a
major issue for me.
Ben
On 10 Jul 2006 at 18:35, [EMAIL PROTECTED] wrote:
>
> 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(localmode)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 toreplace 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 oldhad 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: [email protected] [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: [email protected] [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: [email protected] [mailto:[EMAIL PROTECTED] 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 o n 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]
>
