Yes, I found your thread here.

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.

Is the list of conditions completely open-ended, or are you designing some sort of front-end querying tool where you're selecting combinative statements from drop downs?

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 other issue by the way is that the code you put in your filter condition, especially if its a parameter must use t-SQL syntax.

There is only ever one execution plan for a stored procedure. It is dangerous then to have the same stored proc do different things based on a parameter. For example:

1) where firstname = "Alan"

2) where LEFT(firstname,1) > "A"

Example 1 is highly selective, but example 2 isn't. If you call a stored proc and ex 1 gets called by user 1 for example, and then user 2 tries ex 2, then you'll run into a big performance problem. This is why it is a big mistake to have a stored proc contain conditional sub-queries and to have a "one procedure fits all" approach.

I haven't directly answered your question yet. 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.

Regards
Simon