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