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

I've done it few years ago, just to display the results of an automatic process (a slightly perverse progress indicator), and before eventually switching to a parametrized view, I initially used zappable cursors as grid source, and it worked just fine. The reason I switched to views was not connected to the grid at all - I just needed to have it updateable.

Whether the grid with start blank or not depends on where you first populate this cursor; if it is still recordless when the grid shows up, of course it will be blank, but it will have proper header and columns.

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

The view in a separate database, possibly a local one. It's simply easier to do and maintain. With a cursor, you still need the code to set the grid's columns, since the cursor doesn't really exist at design time. With a view, you can set it up using GUI, which is supposed to give you some ease and save some time.