Steve, Thanks for the info. Are you able to set opportunistic file locking in XP? If so I'd like to check out the third client site.
Also, the tweaks relative to the NIC you mentioned, how substantially do they affect performance? Are they complicated to understand? Thanks Ben On 11 Jul 2006 at 14:56, Steve Durham wrote: > > Ben, > > "opportunistic file locking" ON is a default setting in Windows. With > Windows Server 2003, you can now setup your server for file sharing by > simply running the administrative wizard. This will optimize Windows for > file sharing. Now depending on the network card you have, there are things > to tweak there. You will have to account for the type of security you are > using on your network while making those changes. If this server has some > sort of support, someone should be able to contact them and ask for > assistance on setting up the server NIC to be fully optimized for your > environment. Then the next thing to try is set all your virus scanning on > clients and servers not to scan $$$, rb*, and any other RBase file you use > or create during a session. I would recommend setting this at the file > extension level seeing the files can exist anywhere on the server. All the > above is dependent upon setting up your file shares in a Windows Standard as > well. Hope this helps. > > >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] > > > > > >
