>>>>Hi,
>>>>
>>>>When one of the features of the application is called (VFP form is opened), my application loads ALL records from the SQL Server DB. This is a spare parts table. Let's put aside that - maybe - I need to change the logic and get only those records the user needs.
>>>>Right now, one of the customers has about 25000 record in this table. They timed that it takes from 30 to 40 seconds to load them into the application window. Is it reasonable (I know it is subjective), but in general?
>>>>
>>>>I use the code
>>>>

>>>>select * from MyTable
>>>>

>>>>when pulling all records.
>>>>
>>>>How can I improve the above SQL Select?
>>>>
>>>>TIA
>>>>
>>>>UPDATE. The customer just sent me an email and wrote that sometimes pulling the records takes as little as 3 seconds. Just like right now.
>>>>
>>>>UPDATE 2. Actually I found that the query is not "select * ..." but listing all fields/columns of the table. So, the query is:
>>>>

>>>>select field1, field2... and so on from MyTable
>>>>

>>>>
>>>>I probably need to change this to "select * "
>>>
>>>If both queries are for the same table, having one with select * and another with select (list all field names), will result in 2 entries in the query plan cache and one may not optimize like the other.
>>
>>The SQL Select that I am talking about - above - is used (one time) in the CursorAdapter property .SelectCmd
>>That is, when the CA gets the data, it uses this property. I am sure Walter Meester knows more about query efficiencies and he mentioned that changing from listing all columns (in the SQL Select) to selecting all (select * ) won't make much of a difference. But maybe I will still try. At least, on the surface, I see no harm
>
>Which is rude. Walter knows more about query efficiency than who?

I'm not claiming to be all knowing, but I don't think there are many people having in depth knowledge of the SQL optimizer in the first place. I've spend almost 3 decades optimizing database access, so yes, I like to think I have at least a reasonable level of understanding of what it does,

>2 queries get different query plans. Each plan may have different optimization.

Ok, I'll bite here.

SELECT *  FROM sometable
and 
<Pre>SELECT ...full field list ... FROM

Will most likely share the same execution plan as
1. In both cases the whole table is scanned because there is no WHERE clause
2. The same field output is requested

There is no guarantee though, because even in the case of the same query, the used execution plan could be different from one execution to another (though more likely with parameterized views). The query optimizer, though to some extent predictable, is not exact science. The rules might change from one version to another and even be depended on the metrics of available resources (like CPU and memory).

But the main point, there is no reason to expect a different execution plan (and therefore performance) for the 2 reasons listed above.