A couple of suggestions.

Make sure your views share the connection. Otherwise, each view is establishing a new connection to the server and that is a time consumming activity.

If you are not sharing the connection, and you are using MSDE (instead of SQL Server) it is highly possible that you are exceeding the number of "allowed" connections and thus slowing down MSDE.

Try to trace what VFP is sending to SQL Server. You can use SQL Server "Profiler" tool for this. Check if VFP is sending more stuff than what you expect. With old ODBC drivers, I have seen SQL Server processing memo fields extremely inefficient.

Have you trying to "reduce" the view with that is giving you the problem. Try removing the WHERE clause to see if that is the problem. If that is not the problem, try removing the joins one by one to detect where is the bottleneck.


>A have several remote views fetching the data from MSSQL 7, all of them performing 4 to 6 left outer joins and having 5 to 8 AND'ed parameters.
>
>The problem: one of those views takes TOO MUCH time to open with NODATA option (3-4 minutes), others are ok (I have the same delay when creating view definition, i.e. 'create sql view ... as...' causes 3 minutes delay).
>I moved the definitions to the server (created server views w/out parameters) and reduces VFP definitions to 'select * from /server_view_name/ where /parameter_list/' - that didn't help.
>
>Q1: Could somebody point me to an explanation of how VFP internally parses pre-defined views so I could localize the problem ?
>Q2: Is it possible at all to work with large view definitions on VFP/MSSQL platform without using pass-through/MSSQL stored procedures?
>
>P.S. Actually, when I redefine views both on VFP and MSSQL, the VFP view opens instantly for the first 3-4 times, then comes the delay... Anything to do with MSSQL view parameters?