>Naomi,
>
>>1) The select would be too complex
>There is not a SQL statement complex enough that Sergey wouldn't be able to make it work <g>
>
>>2) What should I do for my grid? Add extra column on the fly? How about sorting (my grid class allows sorting)?
>Why not? Of course that would depend on your implementation of the sorting class, but I do not see a problem (of course I do not like to mention I am very short-sighted)
>
>>3) What if we would like to add a new field, which I didn't specify in my cursor?
>This might be a problem for you will need to ask Sergey again how to build the new SQL statement <g>
>
>[Update]By the way, if adding a field changes radically the select statement, then you can not only use some way of configuring which fields the user wants for you will need a different SQL depending on those fields, so the item 3 remains complex, I think[/update]

I think your idea is even more complex to implement than mine, though it solves the problem with updating. I do not want to make the original cursor too complex either.

In other words, let's assume, that we always want to use one character field, which is unknown in advance and the rest of the fields is fixed.

[(Now, what if the parameters change and we may want several new fields?)]

Then I can have my cursor predefined using some fixed name for unknown field and I may design my grid in design-time.

Having field name and JOIN expression in the memo field allows me to specify select.
=============================

Using your idea I would need to instantiate my grid in run-time instead of design time...