[DB-SIG] dBase III and VFP tables
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
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
More information about the DB-SIG