Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
What Corrupts Indexes??
Message
From
15/07/1999 15:40:12
 
 
General information
Forum:
Visual FoxPro
Category:
Databases,Tables, Views, Indexing and SQL syntax
Miscellaneous
Thread ID:
00241688
Message ID:
00241959
Views:
22
>>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...
>

gurreat! I've been at pains to ensure that every workstation has the latest Client 32 in order to avoid just such problems.


>
>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.
>

will check out the Novell site tonight, the version we're using is Feb 99 so there may well be some updates.

>
>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.

well compression is one feature we don't use.

>I'd send your end-user's LAN Administrator

they don't have one. They want me to do it for them.

>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.

too late for that. Fortunately I had a spare battery for the pacemaker...

>The issues will need to be handled by, at a minimum, upgrading to the latest Client32 versions

that much I can handle...

>and restricting some of the Client32 options,

this I can manage if you'd be kind enough to list the guilty options...

>or switching to the MS Client,

I'll try to avoid that because I really could do without 12 total reinstallations of Win 98

>and mnay require changes to be made at the server end.

ferinstance?

>
>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.

is 3.20 Y2K compliant? That was the main reason this user stepped up from 3.12...


>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.
>

how could I test for such problems. Must confess that apart from this particular issue, the network has been running 'sweet as a nut' and doesn't give any other obvious signs of trouble...

>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 shall pass this advice on. But is it possible to switch from what they have now to a raid or duplex system without major hassle and expense?

>
>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.
>

Gotta say a good word for the Kingstons, they perform up to 500% faster than other cards we tested and they're a pretty good price.

Thanks indeed for this very helpful and informative (if somewhat alarming) reply. It certainly gives us some food for thought!

Harry
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform