>>>Performance may not be a problem now, but when it becomes a problem you'll have to change your code. Why not find a method that works in most cases? SQL is the answer.
>>
>>Mike,
>>
>> I tried this idea, but I had lots of problems, one of them is grid reconstruction, which requires some special code (using Vlad's FAQ).
>
>Another way around it is to base the grid on a read-write cursor; the data pulled go into a read-only cursor which gets killed and recreated each time, and then the read-write cursor is zapped and records appended from the read-only one.

I like this idea. Are you sure grid would not be blank in this case? I'll try it right now.

In that case there's no need to do any grid reconstruction. You can even use a local free table with exclusive use and zap it as needed; RW cursor is simply faster.
>
>> Basically, I have one main grid. Another is a 'child' grid. Do I need to create a view for the child (temp view, I don't want to keep it in a database) and requery it while navigating on the parent table?
>
>You have to have a database to have a view, but then nothing is stopping you from creating a temp database, or to have a separate database to hold views

Lender table is already in Lookups Database, so I can use view. I just didn't want to pollute Lookups database with this view. This view should be for display purpose only. Do you recommend your first idea or the view idea?

only. I'm actually combining these two approaches: each user has his own database which holds view definitions. It's recreated programmatically when needed (i.e. when a new .exe is shipped), resides on local drive, and is probably somewhat faster than one on file server would be.