[DB-SIG] dBase III and VFP tables

Carl Karsten carl at personnelware.com
Wed Jul 20 05:06:42 CEST 2011

On Tue, Jul 19, 2011 at 8:41 PM, Ethan Furman <ethan at stoneleaf.us> wrote:
> Carl Karsten wrote:
>> for those of you that are wondering about this nuttyness:  VFP is a
>> dBase derivative.  In there early days, there was no support for Null.
>>  But a side effect of adding a row but not storing values to it was
>> empty fields.  the best example is a date.  dates are stored on disk
>> as a string "YYYYMMDD"  and in the case of an empty date: "        ".
>> Same with numbers: N(6,2) would store 3.14 as "  3.14" and an empty
>> number was "      ".  Then they added Null support, but instead of
>> using this empty state, they added a flag, so now a field could be
>> Null, Blank or have a value.  which was a mistake, but here we are.
> Thanks for the clarification, Carl.
>> For D/T I am not sure you have a choice.  What value would you return
>> for an empty date other than Null?
> As it happens, I created custom Date, Time, and DateTime objects so that I
> could deal with the empty values.  I probably just should have returned None
> from the beginning, but did I mention that this is the project I have
> learned Python with?


> Now that I have them, I'm thinking of keeping and continuing to use them for
> the empty case... but not sure if that's a great idea, hence my question
> here.

I would say supporting Empty is a backwards compatibility thing: If
there was code that relied on it, then you should continue to support

When I was using VFP I never needed both values.

My guess is the custom objects will cause problems and solve none.

>> for Logical I would return False.  Mainly because I am pretty sure
>> that because in VFP an empty logical will be treated as .f. anywhere a
>> logical is evaluated.
> The test I tried before I left work seems to confirm that (it was just
> printing).

Carl K

More information about the DB-SIG mailing list