When running the same query in Query Analyzer it returns data in <2 sec.
Same results with SQLEXEC(). The problem is that for some reason it takes too much time for VFP to parse (or recompile?) the view definition, even when most of the definition resides on MSSQL.
Example:
SQL Server: CREATE VIEW search_claims AS SELECT ... FROM t1 LEFT OUTER JOIN t2 ON (...) LEFT OUTER JOIN t3 ON (...)
VFP: CREATE SQL VIEW search_claims CONNECTION Claims AS SELECT * FROM search_claims WHERE ...
Is it possible that VFP tries to parse the view definition from SQL server search_claims view?

>You might want to run your SQL in Query Analyzer and see what the bottle necks are. Maybe you need a few indexes on the server to speed it up.
>

>>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?