John,

>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 only wondered how you do it. That's all

>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.

For myself I've found another strategy. I use the local VFP engine for lookup data. Giving me more performance (O.K. this depends on how fast you STP approach is). To manage updates on these local data I use the replication manager to replicate updates either directly or on a scheduled basis to the VFP database with the help of the VFP ODBC driver.

In this way i'm able to store either very static data as data that changes more frequently.

>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.........

Today I gave you one, I'll wait for your answer.

Walter,