>>>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.
Hi Dragan,
Just want to let you know, what I implemented view idea and everything seems to work just fine.
I didn't try to create temp database though, I just add a parameterized view to the existing database.
Thanks for the encourangment.
If it's not broken, fix it until it is.
My Blog