>However, there is one situation come to mind that might make a difference. Our database does use fixed lenght character fields. Returning large number of rows with wide character fields might take up lots of bandwith. Normally this is not really a concern in LAN environments. Our product is optimized to run on high latency WAN network with limited bandwidth. In that case it might be worth to strip off remaining spaces, e.g.
>
>

>SELECT
>      MyField = CAST(RTRIM(MyField) as varchar(100))
>      , MyField2 = CAST(RTRIM(MyField2) as varchar(100))
>      ...
>      FROM Table
>

>
>We have had some good results by limiting the size of the resultset this way. But on a solid LAN network it is not likely to make a significant impact.

The question/topic for me was too clouded/misty as no info was given on network kind and perf characterisics. I realize Dmitry has no direct access, but possible bottlenecks there should be denied or described.

>When only selecting a few view fields from a SQL-server view it becomes a total different ballgame. Unlike VFP, SQL server won't bother to calculate fields in the view that in the end are not used, and optimizes the query for the remaining fields. The query might be a full index coverage type of query where the query essentially is ran on an index instead of the table itself.

True. I am positive Dmitry would have mentioned his query accessing a view, and columnar layout for such tiny table is also very improbable ;-)

I brought those up as theoretical points responsible for my "head scratch moments" after my first thought was VERY similar to your points ;-)

regards
thomas