>7- Relate to 6: Is posible try if send sql commands to a COM server hiting the table not cause this??? Is possible fetch small dataset?? That its, only get one record at-time.

>If you mean that us using a COM server may cause it, no, we don't use that.
If you mean that could be the solution, you are right. I thought about it anyway.

Yes, i mean that using a COM server can help (not solution because the problem still exist, only go away from them :)

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

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.

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

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

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


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

Chaou