Foxpro System Paused during Searching/Updating

[kmlau]

I have a database System written in Foxpro for Window 2.6. The database was stored in a Novell 3.2 server, shared by around 5-6 486-PC (16MB RAM) running Window for Workgroup 3.11.

Recently, I have migrated the PC to Pentium 233 (80MB RAM) of Win 95. In general, the speed of processing for the System was obviously increased. However, sometimes I encountered the following problems which had not occurred in the old times :-

1. When doing a searching/updating for a large database, sometimes it paused for 20-60 sec, and then continue the processing. Meanwhile, there were another workstation doing the same operations.

2. Similar to 1, it paused but now only 1 workstation doing the search. When the same search was done once again, there was no pausing and it run perfectly fast.

Was it normal to take so long for Foxpro to share the database on the LAN ? Or, was it due to that the PC had taken up time for caching ?

Thank anyone for helps !!!

 

[rgbean]

You don't mention the network specs. What kind of system is the server? CPU speed? Memory? Hard Disk Specs? (RAID?) Topology? NIC type(s) and speed(s)? Have you had the cabling and/or the cards checked for problems?

Any special settings for the tables and/or indexes on the server? How many and how complex are the indexes on the updated tables?

Are you running any virus checking software on the server and/or the workstations?

Where do your CONFIG.FPW's point the TEMPFILES? Locally or on the network?

On the right setup, 4-5 users shouldn't cause the kind of delays you are experiencing.

Rick

 

[dgrewe]

Have your network people contact Novell. There was/is a problem in the Novell 3.x software that causes that problem on "Large" DBF files. There is a patch you must load to fix it. David W. Grewe
Dave@internationalbid.com
ICQ VFP ActiveList #46145644

 

[kmlau]

Thanks for the help. I would like to include more info about the File Server:

IBM Netfinity 5000, PII 350CPU, 96MB RAM, 2 x 4.5G SCSI HD
10/100 NW Card (but the hub supports 10M only)
Netware 3.2, NAV for Netware 4

rgbean, I would check the setting for tempfile and config files. I think there should be no special settings and logics for the tables and indexes. Only the database size is a bit large (several are around 10M).

dgrewe, could you tell me the name of Netware patch you mentioned to solve large DBF file ? I cannot find one that is relevant to this. Thanks.

By the way, I just found that the "Utilization" shown on the File Server was normally around 1%, but jumps to around 60% when I try to perform same operations on 2 different workstations at the same time. Is this normal ? How can I check how busy the network link is when I do these operations ?

 

[dgrewe]

The company I was with before had to do it.
I'm with a NT (yeck) shop now.
Do not remember the name of the patch. Your Network People should be able to find out for you from Novell. David W. Grewe
Dave@internationalbid.com
ICQ VFP ActiveList #46145644

 

[Guest_imported]

Hi kmlau;
I am not a programer. I am using an appliction of FP 2.6 on Novel/NT4.0. We have a smae problem as you had. Did you solve yours and how? Thank you. Ben

 

[kmlau]

Hi Fox pause,

It's not sure yet, but we have found that our ethernet cable was actually
shared with another NT system which was an Intranet application. We're
just investigating whether this Intranet application has generated too many
traffic which occuplied the cable bandwidth and causing the trouble.

By the way, is there any way (e.g. by using some hardware or software) to
test how "busy" an UTP cable is ?

kmlau.

 

[ChrisCarroll]

On your original problem, have you applied the fast processor patches for FPW26?

===========

On how busy the cable is: you can usually tell on UTP is just by watching the lights flashing at the hub or the network card. If it's constantly on, it's busy.

Or, on your Novell server, go to the Monitor. One of the available set of stats is packets received/sent on each given network card. Look at how many broken packets the server receives, and how many transmission retries it has. If these are more than a 5 or 10% percent of of total packets received/sent then your network is quite busy. If you're over 30% it's seriously busy.

Or, some ethernet cards ship with diagnostics on their install floppy, that allows you to monitor all packets on the network cable that the card is attached to. Again, look for broken packets as a percentage of received packets.

Broken packages & transmission represent attempts to use the network that fail usually because it's too busy.

Having said all that: You'd need a seriously busy network to slow down a search by more than 3 or 4 fold.

============

1% jumping to 60% processor utilisation is fine on a Novell server with SCSI. I'd say it means working hard and loving it. HOWEVER it leads me to think that your application is not optimised, because it's demanding huge amounts of data. Are you sure you've not accidently lost an index that you're searching on?