> Nope! This is straight VFP and even doing a CAST wouldn't help. The problem is that you can get a NULL from an OUTER JOIN - unless you specifically check for it and negate it using NVL() you will still get this problem. The correct query would be:
>
> In VFP:
>

SELECT CPY.company_name, NVL( CTC.firstname, "" ) AS firstname, NVL( CTC.lastname, "" ) AS lastname  ;
>    FROM company CPY ;
>         LEFT OUTER JOIN contacts CTC ON CTC.companyfk = CPY.companypk ;
>   WHERE CPY.company_name LIKE "A%" ;
>    INTO CURSOR cur_list

>

Ah, the amount of times, I've had to debug a report going wrong because someone hasn't thought about the NULLs.

To add a little bit of extra complexity into things, we sometimes use Crystal Reports to display our reports and Crystal doesn't like encountering DBFs where the field length isn't what it expects (certainly not in the versions we use). So when writting the report code we need to combine NVLs with CASTs in the output cursor. So not only do we filter out the NULLs we make sure that whether NULL or not the field will always be the same length, so the code ends up being something like this:

In VFP:

SELECT CPY.company_name, CAST(NVL(CTC.firstname, "") AS C(30)) AS firstname, CAST(NVL(CTC.lastname, "") AS C(30)) AS lastname  ;
   FROM company CPY ;
        LEFT OUTER JOIN contacts CTC ON CTC.companyfk = CPY.companypk ;
  WHERE CPY.company_name LIKE "A%" ;
   INTO CURSOR cur_list

I don't like to hard code field lengths but it is the most acceptable solution in this case I believe (without writing extra code to examine the field length before the query is executed). If the actual field length of contact.firstname changed the code on the output cursor would have to be changed accordingly but as long as we apply good DB design from the beginning that shouldn't (ha shouldn't) happen too often.