Hi Simon, thanks for the reply.

>The fundamental mistake you're making here is relying on someone else >to do the backend coding for you!! Don't. They won't know how your app >hangs together or which indexes are going to be optimal for what you're >doing.

Not at all. I will be doing the coding depending on user-entered criteria, but I will have to specify what indexes I want setup at the back-end.

>...or are you designing >some sort of front-end querying tool where >you're selecting combinative >statements from drop downs?

Almost. Users will have a variety of textboxes, combos, etc. from which they can enter/select search criteria. When they press the 'Search' button a filter string will be put together depending on the selected criteria.

>If you have a known set of conditions, then it would be far easier to >write a stored procedure and pass it a parameter that indicates which >internal query to run. The issue though you can easily run into is >performance.

The length or contents of the WHERE filter string will not be known until runtime. I may be wrong, but I don't think a stored-procedure would be suitable for this.

>I haven't directly answered your question yet.

I've noticed! ;-)

>The best thing would be >to abandon the idea of a remote view >altogether. Issue a SQLEXEC() but >remember that what you pass it must >be in t-SQL syntax. This way you can build the string using Fox macro >expansion with no problems. Then you just access the data like a >cursor.

This is the best solution I've come across so far. I tried to keep all of my remote views in the .dbc, but it looks as though the complicated ones will have to come out and be sent via. SQLEXEC. I will, however, keep the updatable views in the .dbc, as I think it is easier to set properties, and the filter conditions are relatively simple, eg. WHERE myIdField=?lnMyParam.


Best wishes,
Alan