Data loss/corruption with Novell client

[stevecrawford]

We seem to be experiencing data loss/corruption when we install our DBase driven software in an environment that uses the Novell client on Windows machines. The data and programme is on an NT4 server machine but the common factor on a number of sites seems to be the Novell client. It has been suggested to me that we replace with the Microsoft Netware client. Can anybody help with this issue? has anybody expererienced this problem and found a suitable solution?

 

[cfneumann]

I take it you are using BDE?

Make sure the LOCAL SHARE setting in the init is set to TRUE. Christopher F. Neumann
[dBASE Charter Member]
Blue Star Visual dBASE graduate
ICCP certified TCP/IP Network Analyst

http://cfneumann.us

 

[stevecrawford]

Hi Chris

I am not a programmer but I can pass this on too our programmer. Could you be more specific and explain how I could check the init for true re: local share. Is this a registry setting. I ahve heard that OpLocks (opotunistic locking) could be the cause - seems we can disable both on the NT server and in the Netware client - do you agree with this strategy? Apreciate your concern and response.

Steve Crawford

 

[DClarke]

The problem lies with the multiple protocals you are using. I assume that you are using Win2K OS on the workstations and internet (IP) and Novell uses (IPX). The record locking falls apart in Win2k when both (IP) and (IPX) are used together. The faulty record locking results in on workstation overwriting anothers records (Lost data). We had to move all of the network apps to a MS Server and remove (IPX)

David.

 

[dbMark]

BKtechie said: If anyone out there runs into problems migrating a dBase V app from Netware 4.11 to Netware 6, I have a tip. If you begin to experience index file corruption on large files routinely, check the setting "CLIENT FILE CACHING ENABLED". It should be set to OFF.

Okay, here's a second belated comment from me. We had Novell 5 using IPX and had data issues. Many tables were missing EOF() markers at the end of the DBFs. Sometimes the print job got written into a table. Sometimes it was a BROWSE screen. Occasionally a corrupted index that had to be rebuilt. As the network got busier it got worse. The server wouldn't go more than 45-60 days before it started "thrashing" with lots of disk access but little serving. And when a computer workstation messed up, would always do it again on all subsequent retries after the table was fixed. Only a reboot would return the workstation back to normal. Some stations were more prone to act up than others, but no predictable rhyme or reason why.

Apparently TCP/IP and IPX don't like each other, as mentioned above. Finally we switched to Win2000 server (making Mr. Softie happy, I'm sure) and the problem went away. It was a frustrating experience.

One final idea: If you use data compression on the server, sometimes a INDEX ON [expr] TAG [name] will fail! because the .MDX isn't actually decompressed and so the appending to the index causes an error. (A common setting for data decompression is to not decompress the file itself until there have been 2 accesses, so backup won't trigger all files to get decompressed.) Sometimes I would used the table twice or packed it first to force a decompress, then added the additional index.