Hi, Greg.

> Very good point on the deleted records. I've encountered that problem before and it definitely was the deleted records in the temporary file that was slowing down the USE in the environment I was discussing.
>
>I'd also would point out that if for whaever reason your are unable to optimize a query in VFP, then a table of any size will create a lot more problems than an equivelent un-optimized query in SQL Server.
>
>For single record seeks and optimized locates I completely 100% agree VFP can be lightning fast even with VERY large tables. What I'm pointing out is if you have to operate across a bulk of the records in a 2GB table, I doubt you will have 200 users with split second access.
>
>One example I have right now is a production planning app that generates 14 million+ records every single day and then has to process ALL of those records to build PO's, work orders, and pick tickets. This generates millions more records every hour. Even with only a few dozen users, VFP is not the ideal database platform when you're actually processing and reporting off large tables.
>
>Basically what I'm saying is if hundreds of users have to process 75%+ of a 2GB table, that is a lot different than hundreds of users accessing a single record or two every few minutes.

I agree with most of what you said. In a "big iron" application, DBFs isn't the best platform for data. I think UT itself should be one of the biggest apps I know like that supported over DBFs, but then, being a web application, there is no network overhead for every transaction, and chances for corruption are preety little.

The only thing you should be careful about is your statement about non-optimized queries on SQL Server. A badly optimized, slightly complex query over large tables can hog your CPU, specially if several users start running it and the processing collides.

Of course, SQL Server has great tools to handle this and find a way to optimize things, but beware of this kind of scenarios!

Best regards,