Alan,

The 214,000 records will NEVER actually be obtained in under a second by a *real* (my term, will explain in a moment) SQL statement. Not even if done entirely on a workstation.

The Select statement that you see doing so is actually returning a "filtered result set", which means that it is acting more like a BROWSE statement than a SQL statement.
Adding NOFILTER, as was suggested, prevents that from happening. This gives you an accurate representation of the actual performance required to return the result set, necessary because no VIEW can provide a "filtered result set".

Now 60 seconds seems too long for me under optimal circumstances, so it looks to me like the circumstances are not optimal.
With such a simple Select, the first thing that comes to mind is the width of each record. If it is wide, then a good option is to reduce the Select to only the fields you know you will need.
The second thing is the RAM on the machine where it is being run. This can have a serious impact on performance.
Third, do you have a TAG on DELETED()? Assuming that you run with SET DELETED ON, such a TAG can be very harmful, most particularly if you have only few or no DELETED() records in the table.

good luck



>>Try to run Select * From lrs!Names NOFILTER and compare results.
>>
>>>I have a local VFP table of about 214,000 records. When I execute a simple SQL on it in the command window. “Select * From lrs!Names”, it return all of the records in about 1 second.
>>>
>>>When I create a local view with no filter and no sort it takes at least 60 seconds.
>>>
>>>When I view the SQL generated by the view, It reads exactly like the one I typed in the command window: . “Select * From lrs!Names”.
>>>
>>>Why is the local view so much slower than the typed in SQL?
>>>
>>>TIA
>
>Thanks for replying Sergey.
>
>Looks like the NOFILTER will make the SQL statement as slow as the view but I'm looking to make the view as fast as the SQL statement. Is there anything I can do to speed it up?
>
>Thanks again