[WDx] Database access slowing down

Startbeitrag von Erik Schwarz am 13.08.2013 08:21


more and more customers are changing to new Servers (like 2012) and/or virtual machines and now are complaining about slow access to HF (non C/S) database over Network.

Slowing down is about 10 to 15 times as before.

So I checked the following Scenario:

I have a user app for managment of data and a Background app doing the calculations.

1. Running both on the same machine (Server) where the database Folder resides -> fast
2. Background app on Server and user app on local machine -> user access very slow
3. Stopping Background app and user app still on local machine -> user access fast again.

Remind: this wasn't so with the old machines

So I think it's a problem with the newer operating Systems. Did anybody else see something similar or has even a solution where to set some flags in the os?

Not every customer likes to upgrade to SQL Version where all works well.

Thanks for any hints.



Hi Erik

your 1/2/3 test shows that it's the sharing of the files causing the problem, which leads directly to the oplock (opportunistic locking) management by windows.

This is a well known problem, with only ONE perfectly working solution HFCS. If you really want to tinker with both clientS and server OS settings to maybe solve the problem (till a future upgrade of windows) then you can search the windev forum (especially the french one) for OPLOCK (google translate should help)... But you may find in the end that it's a fools errand

Best regards

von Fabrice Harari - am 13.08.2013 12:16
Hi Fabrice,

thanks for the info. Using HF or SQL is the best solution. With this affirmation that it has to do with Windows OS, I can convince my customers to change database.



von Erik Schwarz - am 13.08.2013 13:02
Hello Eric

Fabrice is right and the reason it is probably only occuring with the new servers is that from Server 2008, if all the workstations are running Vista, Win7 or Win8 ( no XP machines in the mix) then the network protocol becomes SMB2 which forces oplocking to always on.

You can get around it by turning off SMB2 and drop back to SMB1 which then allows you to turn off the oplocking but HFCS is the best answer. The other issue is that HF Classic is single threaded so it can swamp a server with a large task and servers are running slower CPU clock speeds now and relying on multiple cores to do the work rather than a high clock speed CPU. HFCS is multi threaded so the load can be spread around the cores.

You need to move on this quickly because if the oplocking is not turned off then you may get data corruption - I have first hand experience of this If you want to turn off the oplocking for a short term fix here is a link.


von Al - am 13.08.2013 13:26
Hi Al,

thank you for the additional hints, that's just what I supposed to be Problem.
Good Argument to convince my users to Switch to HFCS or SQL.


von Erik Schwarz - am 15.08.2013 07:46
Hi Erik,

at my opinion you should force your users to switch to HFCS or SQL. I have a (10 year old VFP) app which worked really good on servers less than 2008, but running on 2008 or 2012 I am faced with huge problems regarding performance and corrupted index files.
I think it is the same thing with HF Classic.

I do not develop any new App using file based databases like HF Classic.
Regarding my old VFP App I am trying to convince my customers to use terminal services or Remote App Roles, in that case Application is running localy on the server, so you have no problems with OpLocks.

Best Regards


(By the way, you are comming from germany?)

von stefan.kern - am 15.08.2013 20:38
Hi Stefan,

thanks for the next confirmation. I saw this effect with tps-files from Clarion, too.

Yes, I am coming from Germany and living there a few kilometers away from the new mathematical center of the European Community.



von Erik Schwarz - am 16.08.2013 16:47
Zur Information:
MySnip.de hat keinen Einfluss auf die Inhalte der Beiträge. Bitte kontaktieren Sie den Administrator des Forums bei Problemen oder Löschforderungen über die Kontaktseite.
Falls die Kontaktaufnahme mit dem Administrator des Forums fehlschlägt, kontaktieren Sie uns bitte über die in unserem Impressum angegebenen Daten.