Chaim,

The index error can have all sorts of effects. You don't want to continue operating in the hope that the results are minor. ;-)

I don 't believe that frequency of error rises directly as a result of size of data. The risk rises (because presumably the data increases in value) and backup/recovery becomes more problematic.

The main risk is the underlying *reason* for the problem. In desperation some years ago we introduced a locking system that required users to call helpdesk to have our app reactivated on the PC whenever it terminated abnormally. We discovered that a room full of typists with a shared printer were switching their PCs off every few minutes without closing down windows, because upon restart the documents they'd printed would all come out immediately rather than taking forever to walk the regional WAN looking for the printer 3 feet away. This infrastructure problem was causing corruption of our local tables. It can be horribly difficult to track, which is why now is a good time to think seriously about C/S.

The max table filesize is 2Gb for the dbf and another 2 for the fpt though you can go bigger ising 3rd party ODBC drivers. IMHO you need to be considering C/S long before you reach that point, because maintaining a 1.6Gb local table may require hours of exclusive access to cope with an error.

C/S databases are not without problems. However, as long as you keep the server stable, you cerrtainly don't see as much corruption. It does still occur, and many experts advocate regular reindexing, but it's less catastrophic and you can call in big guns to resolve a problem for which you are unlikely to be blamed. You will be blamed for the local table problems, especially by those who'd like to take the work from you.