>>>Hi all,
>>>
>>>I've placed a grid on a form (not programatically in this case) with no controls set to "ReadOnly = .T." but some are "disabled" (under VFP 6). One column has an added combo box. The combo box and one other text box should accept user input. The datasource for the grid is a SQL statement generated at runtime. The grid populates fine, but all the controls come up as "read only" when I attempt to change their value. I've encountered this before but can't figure out what's going on. Any thoughts?
>>>
>>>TIA,
>>>
>>>-Arne
>>
>>Arne,
>>
>>I've re-read your post again. If you use SQL as a grid source, it would become non-editable. You have to create cursor with create cursor command, then append the result of SQL into this cursor. This would make this cursor edittable.
>
>Nadya,
>
>Ah, this all makes sense now. If you SELECT into a cursor, the cursor is not editable. Still strikes me as odd behaviour but I guess that's just the way it is. Any thoughts on why VFP makes the cursor uneditable? I assume that the assumption is made that after the select there is no guarantee that the source table has not changed - hence the cursor does not necessarily reflect the current state of the source table. That said, it seems far more useful to be able to select into a cursor, change things willy-nilly, and then do something useful with the data in the cursor - why should it be implied that you would want to "write" it back to the source?
>
>-Arne

Well, this will change in VFP7.0, where we can use ReadWrite clause in SQL. But currently if you're stick with cursors, you have to make this cursor edittable by yourself or use views.