Mario, thanks for your involvement again.
See below.

>
>>Something about the file-handling error say me that exist a problem with large data (a protocol issue???)
>
>>It looks like that indeed, though hard to prove. I mean, the record size of the tables themselves is not always that big, but around the transaction (other tables involved) there seems to be heavy stress implied on the file system. There are even MS Q's about that, but I never found them really related.
>
>With transaction your meant VFP transaction or File transactions??.

Logical transactions spreading (one record at a time per table) over several tables. As we use it, it is not about the possibility for Rollback, and only concerns the records kept locked untill the end of the transaction, at which time an UNLOCK ALL is applied.

>
>If File:And yes, in the help file of VFP say that put a lot of files in a dir cause strees to the system, and recommend organize the files in more small chunks.

Let's say this is from the old days. Today, both NT and up, and Novell 4 and up platforms have direct access to the dir-entries. For W95 (etc.) and Novell 3 (etc) it implied physical search the directories. This stresses the CPU heavily, though never occur errors from it.
It's not an issue IMO.

>
>If VFP: You can reduce the transaction long???

N/A.

>
>>8- NOT DELETE!!! Put a logic delete, that it, add a field called "Hey man delete it!!!" and build a utility to do a real delete (in the server and use DELETE FROM) running, for example, only a time each day.
>
>>Okay. But really, I don't see why. That is, weren't it for the almost 100 % being sure that deletes preceeded the thing happening. So I mean, looking at the way a delete is dealt with (from the physical angle), I don't see the relation. More complex it gets, when you know that our Deletes are always preceeded with a Replace in order to change the Key. So, I feel you may be right on this one, but please, why do you say it ???
>BTW, "in the server" is not the most easy one running a Novell server ...
>
>I say that because is best touch litte in the client side and run this things in the server. Is more hard corrupt data if not a cable is involved (i.e. local file acces is more safe). So, runing the delete in the server must help in reduce the problem...

Yeah, right. However, it would imply that the corruption occurs at the client level, and it is not. It happens within the Novell server.
But in general, yes, it's true obviously.

>
>>10- Exist codepages conflict!!! Turn all client/serves to the same codepages... for example go to control page and set the same languaje. I have troubles with Sql DataEngine ONLY because a have language set to SPANISH-Colombia...
>
>>Okay, so here might be something ...
>We DO have all at the same code page. It's 850 (IBM Dos or so). Now, I don't expect the 850 to cause a problem (though it might as your Spanish does), but, what about FPD tables not supporting it officially ? And it CAN be applied (without further notice). I sure will dive into this one ...
>
>I absolute sure that is possible change the codepage/without re-create the table) but in this time i don't remember how(is a fox funcion). If you set it to Windows nothing bad must happend (but rememenber that you are living in the Fox Land)

This program is CPZERO.
It just changes some byte, and it does not extend the table to a VFP table (with the longer header length).

>
>
>>No more ideas from now....I hope that you can resolve this starnge trouble and can sleep happy again!!!
>
>>Oh, I can sleep alright. But it's taking too much time really, AND it is VERY dangerous for our customers. In the end it's just a commercial thing (too), and we are just in luck to be able to say : better have NT for the server. This conclusion came after 1,5 years of analyzing ...
>
>I last idea: You try using a SP for the insert/delete/updates??? I don't know if the work of a SP is done rigth in the server, but maybe can help....

Well, if we talk SP as connected somewhere in the DBC (don't ask me whether that's possible), it will still be the client doing it. So it won't change a thing. And, having an SP on the (Novell !) server without the remote DBMS ... don't think so.

Peter