To you John and Walter who love to debate anytime,

Sorry for jumping in but my question is something not quite irrelevant on this issue. When do you use VFP/SQL Server combination and when it is not? In the same way, apply the same question to VB/SQL Server (specific to John as I assume that Walter don't use VB.)


>While I try to avoid navigational lists in a C/S environment... there are two basic scenarios:
>
>For small lists, I still use combos. They get their data via a stored procedure. In some cases, I have had 4 or 5 of these items on a single form. The performance is lightening fast....
>
>For large items, I provide a query mechanisim for the end-user to specify some basic information that would filter a bigger list.
>
>You know, there are alot of C/S systems out there that manage to provide lookup data rather effectively... Do you really think good performance is only germain to VFP data? I know this may be a rude wakeup call, but there it not too much that you can do in VFP that could not be replicated in SQL. I don't count all the set relation stuff in this because that is truly an x-base thing. However, ADO Shaped Recordsets do give me the identical behavior. So, if pressed, I could do that as well.
>
>Now...does this mean that I discount the local VFP engine entirely. NO WAY!!! Often, I find it very effective to render results from SQL into a VFP cursor, and index that cursor to provide an easy way to sort data. I find I only need to do this when I am using a Grid. Remember, with client-side ADO recordsets, I can sort the data just as easily, without round-tripping to the server.
>
>
>I await your next challenge.........
>
>
>>How do you handle lookup data ?