Fabio,

What's the real USE CASE for wanting to be able to create a CursorAdapter that doesn't match the data store? It seems to be far more problematic than useful.

If you make a CA field nullable but the base table doesn't support it, now the CA can't push the data back to the data store where the rows have null values in the field.

>>Hi Fabio,
>>
>>>EXPECTED: The CA must respect the declaration made in CursorSchema.
>>
>>What is the ground for your expectations? Is it documented that NULL/NOT NULL are respected?
>>The nullability of the column is determined from the data source.
>>
>>Thanks,
>>Aleksey.
>
>Of course i known this,
>but:
>Aleksey, this is a bug ( design ).
>On VFP8 CursorSchema allow to override backend's datatype,
>and therefore the override of the property nullable was not supported;
>to limit, but it was the first version.
>
>On VFP9 Team add DEFAULT and CHECk support;
>why not to be able to finish the job, and allow to override nullable.
>Me it does not seem much difficult one.
>I see always this limit in the things that the team make:
>If you do not see a way in order to use one characteristic, then not implemented it, a serious error.