*.dbf searches on 2003 very slow...

[guido45]

Hello

We've been having a problem with DBF databases running on a Windows 2003 Server in a workgroup environment. The (XP) client machines run Clipper 5.2 programs, often doing massive amounts of reads on large .DBF files - when only one client is doing this it runs very fast, taking circa 15 seconds to finish. However if another client also tries to run the search after this it will run incredibly slowly and take 3 to 4 minutes. The databases themselves are still showing as being open files in Computer Management for a while after the client's search is complete - and when they are released the search will run as speedily as before. (The speed of the search if it's run from the server never changes and takes about 15 seconds.)

We have tried various solutions found on the web:
-disabling Opportunistic Locking and Caching in the registry only made every search slower
-disabling "digitally sign communications" didn't apply because we are in a workgroup not domain

Please help!

 

[GriffMG]

My first thoughts were opp' locking.

But in Windies there is another contention; ownership which can cause exactly this problem.

The files you are accessing need to be owned by someone else - other than the user who is getting to them first.

I *think* you can do this from the server console, but the easiest way I know is to copy the files off the server onto a workstation (via a share), remove the originals, and then copy them back while logged in as admin. If you can use the admin account to pack and reindex - this might also work.

I haven't seen an example of this in a few years - so I may have the solution wrong... but I'm pretty certain this is where the problem lies.

Good luck

Martin

Regards

Griff
Keep [Smile]ing

 

[TonHu]

I'd suggest to recompile the app using xHarbour as that's going to give better milage on XP. (But it may sound like I'm promoting xHarbour again ;-) )

I'm also baffled about the Opportunistic locking 'solution'. Did you apply the O.L. fixes to the workstations as well?

HTH
TonHu

 

[guido45]

Thanks for the responses. I tried to change ownership from the server itself (to Administrator) but that didn't make any difference. I haven't had a chance to try it the way you suggested Griff.
TonHu - I tried the Opportunistic solution on the server and two workstations and tested from them only and this made all client searches run slowly.
Is there anything in Perfmon that I could check to see if caching is causing the problem?

 

[DTracy]

Which linker did you use to link the 5.2 programs?

 

[GriffMG]

What you COULD try is getting another user to open the files first and see how the performance is.

Regards

Griff
Keep [Smile]ing

 

[guido45]

We used Blinker 7 to link the progs.

Griff, it doesn't seem to matter who opens the files first, whoever it is it appears to "hang on" to them.

Is there a tool we could use to replicate some sort of interrogation of the .dbf without using our DOS front-end? That way I could narrow down the cause to either Windows or the Clipper program...

Thanks in advance

 

[GriffMG]

Hi,

If it really isn't making any difference at all who gets the files first, then this is back to being a opportunistic locking problem - at least *I think* it is.

Short of writing another DOS program you can't really do much in the way of interrogation of the .dfs - you could try opening them in Access - but the tables could end up spoilt, particularly if they have memo fields.

I would double back and look at the op' locking - there are different approaches to turning it off now, dependant on the server OS - you are using 2K3 so you need to follow the instructions here

http://support.microsoft.com/default.aspx?scid=kb;en-us;296264

- you may need to restart to make sure it picks up properly.

Each of your workstations may need configuring too - that will depend on THEIR OS... you say XP, so the above instructions should be applied again... al a bit of a drag!

Good luck

Regards

Griff
Keep [Smile]ing