>OK. I don't understand how I missed this. This obviously just went right over my head. I knew my views were not always optimized. I accepted that it would be slower but I guess the part I missed is I had no idea how much slower.
>
>So I guess that is the answer I have been seeking. VFP can be horribly slow if your views are not optimized and you have a good bit of data and you will have multiple users. Hopefully this will serve as help to keep someone else from having this issue.
>
>I would appreciate your input.
>
>As I stated earlier I am trying to move to TSQL. I am worried that doing so may not alleviate this issue. Would it be true to say that I should optimize my views (meaning make them fast whatever that consists of) BEFORE switching to TSQL? I am NOT referring to making them faster so my users have a better experience until I get to TSQL. I mean is this something I had better do because TSQL will not work much better unless I do so.

I'll try to stay away from giving direct advice, just like anybody else on this forum would. YMMV, etc. Because whatever I say may turn out to be exactly wrong for some situation.

There's a difference between optimizing for dbfs and optimizing for SQL, as in the former case ALL of the data - what the database engine reads to get your recordset, including tables, indexes and fpt files (most often, just large chunks of each) is what gets over the wire. In SQL, these reads are internal, frequently cached internally, and depend mostly on which indexes are available and which are actually used. SQL server does a lot of optimizing itself (but still can't avoid doing the work you tasked it with). So that's somewhat different and the general feel will be different - some things may become snappy on SQL but some may have some delay, and probably not in places where you'd expect.

All in all, start trying things out. See what's faster in your situation. Weigh your time against users' time.