Hi David,

>Frank,
>
>I'like to address this one line of your post:
>
>>******** I would have expected the PADR fieldtype to be C because PADR(field1,10) is a fixed string of 10 characters
>
>I believe that padr() should return the same type of item that is passed as an argument. Send it a char it returns char. Send it a varchar and it returns a varchar. Send it a numeric and it returns a char for backwards compatability. Varchars are allowed to have trailing spaces.
>
>cast() is in the language to provide type changes.

I have no problem with the way it works, it is just that the PADR() is used right now in VFP8 to act like a CAST( as C()).
So existing code can break when a varchar is created because SET("VARCHARMAPPING")="ON" (which is the default) and that varchar is the field of the inner SELECT that gets 'joined', even when PADR() is used to get the string of the right size.

For instance I have this kind of code:

SELECT PADR(UPPER(alltrim(cEntity))+".DBF",240) AS cTable from ddEnt INTO CURSOR _Keepthem

(file_name is C(240))
delete from dd1 where file_name not in (SELECT cTable from _Keepthem)

That breaks at this moment with the default settings of vfp9. (All my records got deleted)

I gave the options of how I can fix this in my reply to Fabio, but the easiest for me to implement was to SET VARCHARMAPPING OFF in every datasession. (I added it to my relevant baseclasses)
So I hope the MSFT will change the default of VARCHARMAPPING to OFF so it will not break code that uses the "NOT IN SELECT(" in SQL commands.

As I stated to Fabio, my main focus is not to define the best practice in VFP9 (that would be using CAST() ) but to try to make existing code run in VFP9 with the least amount of changes to it.

Regards,