Ed,

I'm glad I happened to glance at your post. Our most widely used app is an old FP DOS app that has suffered a few index errors over the last month. I also happen to know that the network folk are deploying Client32. I'm going to pass your message on to the folks that work with that system.

Thanks,

PF

>>I have a problem on one of my user sites which has been going on for months and I can't get near it!
>>
>>Intermittently, about once or twice a month, the users try to enter the system first thing in the morning and are met with the error message 'Index does not match database, recreate index (etc)' and we are forced to restore the previous days backup of the file (much quicker than reindexing 200,000 records on a network).
>>
>>It is always exactly the same file which reports being damaged. In the sequence of files being opened, this is the 18th file that gets opened.
>>
>>For many weeks I thought it must be a bug in my nightly cleanup routine with gets rid of blank records, packs and reindexes all the files etc. So I spent many futile hours trying to recreate the condition. Then the users admitted that invariably the problem doesn't occur very first thing but only after they've been in for half an hour and have already run that day's automatic picking list. So then I turned my attention to the picking list routine and again could never recreate the problem.
>>
>>This week its happened twice. Once after the picking list and once before. But now I've managed to get the users to keep better track of the sequence of events. It isn't helping! Monday morning the problem occurred immediately after one workstation reported a 'low virtual memory' problem and had to be rebooted before it could get into the application. (Note: They had not managed to enter the app before the low memory warning.) On successfully entering the app, bang! The index appears to have spontaneously corrupted itself and no-one else could continue till we replaced the offended file.
>>
>>Today, one user got in with no problem and was happily beavering away but the second user trying to get in got the corrupt index warning, after which the first user could no longer access the injured area. On this occasion no events, unusual messages or system warnings appeared on any workstations or the server. And the workstation on which the error first surfaces has been different nearly every time.
>>
>>Has anyone got any suggestions as to how I can at least narrow down the possibilities?
>>
>
>I'd bet on it being a problem involving the Novell Client32 software, which has been notoriously unstable in conjunction with NW 4.x. There have been lots of reports of problems, lots of new releases of the Novell Client32 software that have claimed to fix various problems, followed by more bug reports and yet newer releases...
>
>I've had much better success with the MS Client for NetWare than with Novell's Client32. Unfortunately, once Client32 is in place, you're looking at redoing the Win9x install to get rid of it - Novell's uninstall is not too good. Supposedly, the most recent upgrades to Client32 have addressed many of the problems, which seem to be common to many file-oriented database products, not just VFP.
>
>There are settings related to write caching and packet burst that affect the stability of the Client32 software with databases. If even one station is using local write caching, it'll eventually cause problems with data files on the NetWare server. Turning off the features that cause corruption unfortunately also degrades the performance of NetWare, so many times users will bitch and reenable the problem-causing features to get the speed up, screwing things up for everyone. And there are features on the server that cause problems, too - the use of file server data compression is a guarentee of problems with data files.
>
>I'd send your end-user's LAN Administrator out to Novell's support web site and have him take a look at the range of problems that Novell admits to be responsible for as far as these problems, and make sure that an EMS technician are on-site to deal with the probable heart attack. The issues will need to be handled by, at a minimum, upgrading to the latest Client32 versions and restricting some of the Client32 options, or switching to the MS Client, and mnay require changes to be made at the server end.
>
>FWIW, at my own company, where we have a mixed NetWare/NT Server environment, we decided to remain with NetWare 3.20 rather than going to NetWare 4/5 in-house; we've enjoyed the same stable environment we had with our previous NetWare 3.12 environments. We're small though - only two NetWare servers, and there was no overwhelming need for NDS.
>
>We've got some very large clients as well; one that I work with closely, with several hundred NetWare servers and a real need for NDS, did not migrate to an NDS environment until they were satisfied that they knew how their own applications would be affected, and did not authorize the use of Client32 until they were able to get the settings for the version of the Client32 software that they support in-house to be stable, and do not allow changes or upgrades to other Client32 versions or enable new features on the server without extensive testing, and they've made changes of version mandatory, and only done in in situations where all users were notified of the upgrade in advance and had their PC Support people thoroughly prepared to deal with upgrade issues. it's worked well for them as a result, although they've been caught with a couple of hiccoughs along the road, too.
>
>>The system consists of a dozen Win98 workstations. all with a minimum of 64 MB of RAM and all with well over 500 Mb of free space on their local hard drives. The Network is Novell 4.11 running on a PC Server with 512 Mb Ram and a SCSI drive. The Network cards are all Kingston KNE110TX 10/100s and its running through a 16 port hub.
>>
>
>This is a small-scale environment, so the need for NDS is not overwhelming. I'd look at server configuration as well; you may be running into problems with the address space and the SCSI HA with 512MB of RAM - cutting back to 256MB or 384MB might well alleviate some problems related to the NetWare SCSI drivers.
>
>A detailed knowledge of the hardware would be needed to determine if this were the problem, but they've made some very poor choices as far as their hardware investments from my POV; for example, a single SCSI drive and 512MB of RAM seems to be a particularly poor decision. The use of RAID or at least duplexing, with less system RAM, might well give significantly better throughput on the disk system, especially on large block accesses, and would provide much better fault tolerance (there is none now as you've described it; the failure of the HA or disk takes out the entire system.)
>
>I don't know the Kingston boards, but my own experience has made me select major LAN vendors for NICs and hubs, and I use NICs specificly designed for the Server environment in the file servers at our office. We use 3COM products by preference, although we've had considerable success with the lower-cost NetGear 310TX network cards.