Glenn,

A few remarks :

If you have (up to) 50,000 customers, just over 10 orders per customer is rather poor, isn't it ? So, have fewer customers or more orders <g>
And what about order lines ?


If you have three tables you have a few retrieval (print) functions as well;
Put some real nice indexes on the tables, and don't be afraid of that;
Most of our customers have over one million sales orders (lines) (just sit and wait for a few years) reaching 1G for this table only. We have 17 indexes on this table, and nobody notices (okay, until you reindex).
So, make the retrievals anticipate on your indexes, and go.
Yea, don't go if you don't do that, because you'll get sued. With SQL DBMS you may go for it without indexes, but still wait and see.

Having normal native dbf and corruption ? yep, can happen, but it would be stupid to have it as an argument. Really. However, use NT for the server, and teach the users not to switch-off PC's anyway (Novell implies corruptions far more easy on power-downs).
Have a UPS on the server and all is fine.

Never think that a table-size or number of records will bring you in trouble, unless you use Locate For without While clause and preceeding Seek. So, the indexes again.

There is much more to say, but IMO this is enough for you. Believe me, this is rather small ...

Cheers, Peter


>A client wants to run a VFP system with
>Three Tables...
> Customer table up to 50,000 records
> Person table, linked to above, up to 300,000 records
> Order Form Table, linked to Customer, up to 700,000 records
>
>Under LAN I am afraid of data corruption and speed issues, as the software does many different queries that are not indexed.
>
>Under SQL I am not concerned with data corruption, but am still concerned with speed, especially if 30 people query the Order Form Table simultaneously.
>
>Has anyone ever dealt with tables these sizes and this many users. ALL input would be helpful.
>
>Thanks,
>Glenn