>>>The other alternative is to build the child cursor (without indexes) each >>time a user changes records in the parent table. If the user selected a >>different row, you could call the SP that builds the child cursor again. >>AfterRowColChange event.
>
>That would mean excessive round trips to the server.

That may be true. It's a situation you may have already looked at. What is "excessive"? If you have a system with a parent table of thousands (or 10000s) of records and each parent has many children then I would say it wasn't "excessive".

If the first hit brings down over a hundred thousand records into your child table and then you have to go through the process of indexing it, that would be excessive to me. *s* But if the system loads quickly (just the parent table and the children for the first record), and then I have to wait very briefly (sub second) to move from record to record, I call that a great trade-off. If you keep the connection open for the life of your application (and not initialize it each time), I think it would be very acceptable.

However, if the tables we are talking about are hundreds of records with only a few children each then I would agree it is adding overhead without needing to.