Thank you for the feedback Mark.

I was thinking along the lines of FetchAsNeeded and Prepared going hand-in-hand. If FetchAsNeeded works as stated for my controlling view, I could theoritically 'prepare' my child views before requerying. This scenario usually is the case when our program opens a formset-based editors. We incur big speed slowdowns during the initial loading of data.

>My guess would be no because the view is using a different connection handle than the SQLPrepare did. However, if the SQL is still cached in the memory of the server database, then maybe. I do not think you can always depend on that. Personally, I have never understood how this gains any performance over just using SQLEXEC without the SQLPREPARE. Seems the server is still going to perform the same sequence of steps.
>
>The following paragraph from VFP Help on SQLPREPARE further confuses the "view" issue:
>
>The SQL statement can contain a parameterized WHERE clause, which creates a parameterized view. All parameters in the WHERE clause must be defined before SQLPREPARE( ) is issued. For example, if the parameters are variables, the variables must be created and initialized before SQLPREPARE( ) is issued.
>
>
>>Hi all,
>>
>>Can I use SQLPrepare with remote views as such:
>>
>>

>>* assume a database is open
>>* assume tables: saleshist & prods exist
>>cYearWeeks = "200301#200302#200303"
>>cSQL = "select prodid,prods.name,yearweek,sold from saleshist,prods "+;
>>       "where yearweek=?cYearWeek"
>>
>>sqlprepare(oApp.ConnectionHandle,cSQL) && does this help speed up the query?
>>cursorsetprop("Prepared", .t., 0)
>>
>>create sql view (cViewName) remote connection (cConnName) shared as &cSQL
>>use (cViewName) in 0 alias myRV
>>
>>alines(aWeeks,cYearWeeks,.t.,'#')
>>for i = 1 to alen(aWeeks)
>>   cYearWeek = aWeeks[i]
>>   * is sqlprepare useful here?
>>   requery("myRV")
>>endfor
>>