TOPIC:

Hi all!

The last 20 years we work allmost all our apps over MS SQL , so my DBF experiance is really small..

We have a DBF/CDX app that deals with Mechanical Projects financial control. It has some DBF's that deal with work details (something like timesheets for workers), that we have to summarize when entering the project window.

Of course this should be built in SQL but for legacy reasons it still stands with DBF/CDX.

Sudently a new customer - with 3-4 users over network started complaining for bid delays WHEN A SECOND USER WAS USING THE PROGRAMM!.

We tried to reproduced in our office and were astonished to find out that a typical DO WHILE inside a scope containing 2800 records (we use the proper index of course) was taking:

- 0,5 seconds when only one user runs the programm
- 24 seconds when another user uses the files from another workstation

Is this as expected?? Do I miss something??

Any ideas appreciated.

Stavros

Hi Stavros,

Just to absolutely clear, this is with VO, is that right?

Hi Stavros,
if you are talking about VO: yes, that is it.
When only one user is using the database, the client caches a lot, so it is much, much, much faster.
I can only give you two solutions:
- cache whatever you can in your application
- change to SQL databases

AFAIK the difference is so large not because the multiuser access has slowed down so much, but because the single user access has speed up.

We have similar complaints from a lot of customers, and unfortunately ADS is no solution.

Wolfgang

Stavros:

It's been awhile since I encountered this but your post jogged my memory. It might have something to do with Opportunistic Locking

Here's the relevant Microsoft article.

Here are the user instructions I added. (Can't remember when I wrote this, but it's on our website.)

Edit each computer's registry to disable Opportunistic Locking on both the clients and the server. (Note: Monkeying around with a computer's registry is dangerous, which means you should enlist the help of someone who knows how.)

To disable oplocks on a Windows client PC (the computer that accesses the server), change or add the following Registry value:To disable oplocks on the SERVER, change or add the following Registry value:Stavros, these instructions were intended for old Windows server editions so I don't know if it will help in your case. But this is one potential solution that should be relatively easy to test.

Stavros

This is a reg file I use for the problem you have described. Run it in the server and in the terminals. It need Windows compatibility with SMB1 (Control panel, Programs and features, Turn Windows features on or off).
I hope this can help.

REGEDIT4

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MRxSmb\Parameters]
"OpLocksDisabled"=dword:00000001
"CscEnabled"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters]
"EnableOplocks"=dword:00000000
"CachedOpenLimit"=dword:00000000
"autodisconnect"=dword:ffffffff
"EnableOpLockForceClose" = dword:00000001
"SharingViolationDelay"=dword:00000000
"SharingViolationRetries"=dword:00000000
"SMB2"= dword:00000000
"SMB1"= dword:00000001
"ConnectionNoSessionsTimeout"=dword:ffffffff

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters]
"UseOpportunisticLocking"=dword:00000000
"UtilizeNtCaching"=dword:00000000
"UseUnlockBehind"=dword:00000001
"UseLockReadUnlock"=dword:00000000
"EnableOpLocks"=dword:00000000
"EnableOpLockForceClose"=dword:00000001

Thanks all for your effort to help.

Unfortunately the registry settings suggested didn't help. Nice things to find out 33 years after dealing with DBF's

THE SOLUTION

(I’m talking loud to myself, as though you hinted to it somehow I didn’t get it at first..)

Well just tested that if we put all DBF/CDX files in C:\Appdirectory\ in ONE PC and run various instances from various windows users on this machine through RDP , all work fine and fast for all users.

On the contrary when accessing DBF/CDX files from a certain shared drive over a network the problem rises and access to files is dramatically slow when another PC uses any of them. The reasons for this are well described on this thread.

Thanks all for your thoughts and help!

Hi Stavros,
of course, the RDP solution is the best one.
For smaller customers, you can look to AADS: www.aads-worldwide.ch/
It transforms a Windows client machine in a terminal server (home versions excluded).
Wolfgang

I would have suggested ADS, not used non ADS for multi user since AXS3 in the mid 1990s.

Always found the non client server RDDs too flakey for heavy multi user.