Albert,

Wayne and Shaw both touch the topics you should look into. I can add some 2c to it :

If possible, shut down DHCP (THE reason for disconnects and reconnects).
Note that it may be running without you explicitly telling it to.

It's not that much a matter of getting the latest Clients32 software, but the one which does the job in your environment (yep, no way of working). Anyway, shut off all cacheing, locking etc. features. For VFP they only disturb, and performance won't be worse (for other software it may).

It is very well possible to have a Novell client, but to our experience, indeed, it is better to have the MS client. Features that won't work : well, the main is PCONSOLE. IOW, have one PC in the network with the Novell client running, and don't use it for the app.

In our experience, once you have problems in the area of client software, in 99 % of cases this comes out beyond VFP running. IOW, setup some test directories with larger and smaller files. Make all that large, that an XCOPY will take some 10 minutes or more to copy the lot. Copy from network to network, and do it by means of XCOPY. No matter whether Novell tells that you should use NCOPY. XCOPY just should work, and if not, there is a problem somewhere. Now, the ultimate test is having two tasks at the same PC, both performing an XCOPY task at the same time. In this situation, try all mixtures of copying from network to network, network to PC, PC to network (PC to PC is useless). If this all just works, you shouldn't expect additional problems within VFP. But, if something is wrong with the client, it will come out already. Now think of it : it won't be VFP, and testing is very easy. Problems will come out within seconds or minutes, and can be repeated. Now start changeing client-parametrs or client software. Until it works.

When you receive illegal seek offsets from VFP, and the PC's (hardware) themselves are okay, it's near to 100 % it's a client software (setting) problem. Note, though, that you always may be dealing with cabling/switch/router problems. This is not likely. But, when the problems always occur around the same time on a day, do start think of this first (switching off/on lights/PC's can easily imply you problem).

For more "heavy" environments, W98 sure is not the best. Use W95 (runs VFP7 runtime) or W2K/XP instead.

BTW, it's not the app hanging, but the interface between the WIN-OS and the (network) drive. IMO it can't be trapped, and only when you are "in luck" you receive the File read error.
To my experience, the OS *can* run into a loop, and the abortion of the task just takes much time. You should notice this by all becoming very slow.

Last note : When you start changeing client-software, depending on from which to which, settings of the previous versions may remain. Don't triple over that, and look at the registry to find setting of the old version. So, no matter whether the old version isn't there anymore, once it's in the registry, things implied keep active (this is a harder job, and you'd really have to know where to look for).

HTH,
Peter


>Anyone have a "tweak list" for Client32 on Win98 machines for a VFP app running with data on a Novell 4.2 server? The app hangs every now and then (only about once every two weeks per user) but we cannot roll it out to the entire company until this is solved.
>
>If you do the big Ctrl-Alt-Del when the app is hung, it says that the app is "not responding". By this point though, it is hard to even terminate the process and usually it means a hard boot of the PC. It sortof "feels" like some sort of communication problem with the server since it happens just about always when the user presses the Save button. The app is written using VMP's framework, which has the proper error trapping, but it doesn't even get to a VFP error because the .exe is somehow just hung.
>
>Albert