Mario, wow !
See below please.

>Welcome to the Fox Land, where not quite often normal things happens !!!
>
>Ok, that maybe sound basic, but:
>
>1- You use TCP-IP?? NetBios?? Two Mixed???. TCP-IP is best, so quit any other communication protocol (i heard that somethings with multiple protocols some data is send in one and the other data is send in the other...)

Because all looks much like floating network packets, it's the first we got rid of. Similar was DHCP that gets around while you don't even know it (- use it).

>
>2- How many records you manipule? This is caused in any table, or only in a specfic table???

Random tables, random amount. At ourselves, it isn't much really.

>
>3- Rebuild the table... I get strange things with a table when null-rare chars come... The ONLY workaround is build a complety new table and re-insert the data. Not work if you run a table-fix utility in some cases

In your case, this must be about some corruption in the header, without really noticing it. Could be FPD created tables (as your suggestion further down the line), an applied code page (same).
There could be something in this ... (see below).

>
>4- Are you try explicit insert??? that is, INSERT INTO (Any) VALUES(DefaultValue)

For some (corrupted) tables we do only that, for others we do only Append Blank, for others it's mixed. No line here.

>
>5- You use pessimist, optimist, row or table locking??? Is more safe turn optimistc-row locking...

All "safety" regarding this has been applied. There isn't any "speeding up" parameter (client) in effect anymore. Which btw doesn't say much about the registry, knowing that some is hard to find.

>
>6- WHY YOU DON'T HAVE A Client/Server design!!!! If this cause troubles so long time ago, maybe is time to go away file-acces and turn it in a n-tier layer... With the time spend in looking a answer maybe you can re-write the whole app...

To some extend you are right. I myself alone spend a couple of hundred hours on this by now. But you know what ? you get those paid if you convert our app in the same time < bg >. No really, it's too much. But anyway, we are surely working on it (merely for commercial reasons).

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

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

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

>
>9- The tables come from FPW and simply use it??? Rebuild all tables in VFP...

Yep, and can't touch them anymore in FPD. Won't do for us.
But please note that the problem occurs just as well in FPD not ever touched by VFP programs. It occurs in the mixed situation too (both FPD and VFP using the same tables), and it occurs in the stand alone VFP environment too. It just isn't related. BUT for one thing : the code page (see below).

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


>
>11- if use a string key, you can replace it for a integer key????

Yeah, heard that one before. But unless I move to generated keys (or GUIDS) it really can't be done. And in my personal opinion, generated keys is nothing. But anyway, the problem concerned didn't seem related again. IMO it's not a Fox problem at all, and it's within the Novell server. I really can't see how THAT relates to integer keys. So, if anyone could say it is ...

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

Thanks,
Peter