>the issue is not "to understand what ago VFP after that it has made it",
>but to preview what it will make.
>
>To remember all the rules that generate a CHAR or VARCHAR is useless.

I still don't see what the big deal is.

>I say that the documentation is corrected, and that the implementation is mistaken
> (I know also the reason, but he is along describing).

I dissagree with you and consider current implementation correct.

>
>You say to use CAST().
>Possible, but it has been implemented badly and it is much slow one.
>
>The much most effective one if logic overthrew ( as current documentation ):
>

>with OFF = > always CHAR
>with ON = > always VARCHAR
>and to leave CAST() in hand to the developer for the little cases to control.
>

See above

>However,
>I see that the Team very rarely places the problem
>to maximize the determinism of the result.
>
>

>
>>* EMPTY STRING IS MAPPED TO VARCHAR(1)
>>SELECT;
>>	SUBSTR('ABC',3,1)	;	&& CHAR(1)
>>,	SUBSTR('ABC',4,1)	;	&& VARCHAR(1)
>
>*** You cannot represent empty string in char field
>
>***** This is a contradiction because with OFF this return two CHAR(1) fields

********* No contradiction here. The empty string is not the same as the space.

>

>
>Of course,
>I did not wait for that this comes changed to me,
>but only send these messages in order to stimulate the thought of who
>I will have to make of the choices for the next one release.

Again, see above.