[DB-SIG] dBase III and VFP tables

Carl Karsten carl at personnelware.com
Wed Jul 20 01:53:57 CEST 2011


On Tue, Jul 19, 2011 at 6:39 PM, Ethan Furman <ethan at stoneleaf.us> wrote:
> Greetings,
>
> I am finally adding Null support to my dbf package
> (http://pypi.python.org/pypi/dbf) and, as usual, the VFP side is being a
> pain.
>
> The issue is that the Logical, Date, and DateTime field types, even when the
> table does not allow Null values, can be empty -- and when Null values are
> allowed, those fields can be empty or Null.  (Empty pretty much meaning not
> initialized -- neither True nor False, and no Date nor Time.)
>
> At this point, also, my module does not support the DB API (that is a goal
> though), so right now you pretty much get direct access to the physical
> table.
>
> My question:  for the direct access side, is there any advantage to treating
> an empty L, D, or T field differently from a Null L, D, or T field?  Or
> should they be semantically the same, always returning, for example, None
> whether it's actually Null in the table or just empty?

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.

For D/T I am not sure you have a choice.  What value would you return
for an empty date other than Null?

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.



-- 
Carl K


More information about the DB-SIG mailing list