Ken,
I prefer to build remote views on the fly anyway with a temp DBC. I've had
so many problems maintaining DBC's that making them on the fly has been more
robust and reliable. Our app also uses SQL7 and local tables, so this approach works well.


>Ed,
>
>I can handle it with little problem in SQL Pass-through, but I need to find a way to do it in a Remote View. that is the big issue.
>
>thanks,
>Ken
>
>
>>OIC, all of our code goes through a sql class, so it would not be very difficult at all to build the left of the where on the fly and leave the
>>parameterized portion in there. Of course I'm sure you've already thought
>>of that since we're not familiar with your goals.
>>
>>
>>
>>>Ed,
>>>
>>>Yes that is fine if you know what fields you want to search on in advance. In my case, the fields as well as the values must be determined from user choices. In other words, everything after the word WHERE needs to be "parameterized"
>>>
>>>thanks,
>>>Ken
>>>
>>>>Parameterized Queries (ie where ?var) are handled by the VFP ODBC converter,
>>>>and are invisible to SQL server. It translates even SQLEXEC calls.
>>>>
>>>>For example: This works just fine with SQL Server 6.5/7.0
>>>>
>>>>ox = sqlconnect('localserver')
>>>>=sqlexec(ox,'USE MYDATABASE')
>>>>cParameter = 'SMITH'
>>>>=sqlexec(ox,'SELECT * FROM CONTACTS WHERE LNAME = ?cParameter')
>>>>
>>>>VFP catches the ? and substitutes the parameter for you.
>>>>
>>>>>Hi gang,
>>>>>
>>>>>In VFP - I have lot's of local views along the line of:
>>>>>
>>>>> "Select foo from mtable where &cWhere".
>>>>>
>>>>>This allows me to construct highly variable where clauses on the fly and gives the user the ability to construct searches from lots of different criteria. It works GREAT in VFP and I don't wanna lose it as I migrate to SQL7.
>>>>>
>>>>>Now - obviously SQL 7 doesn't get the macro-expansion, so the question is: How do I accomplish this same thing with Remote Views or combination of remote and back-end views?
>>>>>
>>>>>thanks,
>>>>>Ken