>>>Kind of a long story - but - I was having trouble getting a .dbf to be the data source of a mail merge. Word came back with "Word was unable to open the data source". When I looked closer at the table in the data session, I noticed that the date fields were marked as nullable. When I removed that check, then Word Mail Merged my table. None of the fields values were actually NULL, just the indicator that they could be NULL stopped the merge.
>>>
>>>So ... I want to put some generic code together that will read any .dbf, field by field, and determine if the value is null to set to EMPTY, and to set to NOT NULL. Can someone get me started?
>>>
>>>Thanks
>>>
>>>Brenda
>>
>>Wouldn't that be like taking the engine out of your motorcycle, and mount pedals in stead? The NULL feature is extremely useful, and in many cases there are hardly any alternatives. For the Word merging, I suggest that you create a temp table for this use, without the NULLs, and delete the table afterwards. For VFP, see SET NUL, SET NULLDISLPAY and NVL() for tips.
>
>It is a old home grown ad hoc reporting tool. Since we upgraded to VFP 9 and released a new version of our software, the NULL field definition creeped in. We do not allow nulls in the tables, in fact NULL is not referenced once in our code. The clients wouldn't know what to do with NULL on a custom report if we did allow it in the tables.
>
>Just trying to get a ad hoc report to work that use to work before we released a new version of our software.

I guess that you get the NULLs as results from some SQL SELECT statement? If so, the NULLs means that no match is found, and this is the correct value according to ANSI SQL standards. I suggest that you use the NVL() function for the offending fields, unless you decide not to follow the standard.