Multiple users accessing VFP App / dbase database over network - slow issues

Question

I'm currently running a VFP9 application that uses a database which is basically a folder of multiple DBF, FPT and CDX files.

Now this database is basically shared on the network (1GB network/switch/PCs) for over 50 users to access.

Now at times we are getting an "attempting to lock" message. I've inspected the hardware with no issues or bottlenecks found. Also at times over 50 people could be accessing or even writing to a specific file within the space of a few seconds.

I've come across potential issues with "Oplocks" in the Lanman area via Google but this doesn't seem to exist in Windows 2008 R2 / Windows 7. Also been reading up on SMB in general but I am at my witts end.

I don't know what to look at next? Maybe I am testing the limits of what a VFP/Dbase system can do?

Could anyone help?

Thanks Ryan

Answer 1

Could be lots of things, and could be perfectly normal Have you source code for the app ?

" .. over 50 people could be accessing or even writing to a specific file within the space of a few seconds .." means no surprise to me you're getting locking conflicts.

The Attempting to lock message just means more than one person trying to access the same record (or file if crude locking).

Have the number of users increased lately ?
Was the system designed for this volume ? Is it affecting one particular feature of the software (most likely should be), or is it all over the system in several features ?

The technical limits for VFP are (I think 2 GB per single table) and practically it gets slow when there are millions of records (huge generalisation). Good indexing will help when tables get large

Is this an intermittent blip on the system (Eg at Lunchtime and evening clock-out times) or is it a continuous or more frequent load on the system ?

If you have source code you can do a lot, if you haven't you need to figure out which DBFs are being locked (they'll be the ones with lots of records in them and probably big file sizes too, when you look at the directory)

Do you have VFP itself or is this a compiled EXE ?

You've lots of options and things you can do, but more info needed.

Nick

Answer 2

For the application slowness, one thing I know can be an issue, especially if you have 50 users pounding on a VFP app. Is the application being run from the SERVER... I mean, does every user have their shortcut pointing to something like

S:\SomeShare\YourVFPApp.exe

If that is the case, then that can SIGNIFICANTLY kill performance. It is pulling the application down over the network for every user sucking up traffic. What I have done with clients is the following. Pick a spot on the local C: drive of the machine... ex: C:\NetworkApps and copy the YourVFPApp.exe into this C:\NetworkApps folder.

Next, create a new shortcut pointing to the C:\NetworkApps\YourVFPApp.exe and save it.

Next, modify the shortcut but this time, change the "Start In" folder to the original location such as "S:\SomeShare\". Save changes and run THIS version of the shortcut.

What this is basically doing is running the app LOCALLY, but by starting in the same final location that is being shared (especially if hard-code paths were implemented and horrendous to deal with). What this does is prevents the need of all users getting the applications over the network and just dealing with the actual tables and data traffic.

Yes, this can be a bit of a pain when there are application updates, but for that, I've written another VFP simple app that looks to the local drive, compares the exe to that of the "latest version" as on the network share. If the server version is newer, copy that locally, THEN launch it starting in the expected "S:\SomeShare\" folder.

As for locking, if you are doing TABLE locking vs RECORD locking, you'll obviously see more delay issues of waiting for lock messages, but clearing possible network bottle necks on the application end might help alleviate it for you.