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 ?