Re: [Dbfpy-users] VFP9 and the _nullFlags field

[alexander s. <al...@go...>]

Jason McPheron wrote, at 22.10.2010 23:01:
>
> Apparently VFP 9 introduced an optional feature that adds a hidden field
> to a DBF file called "_nullFlags".
> More information:
> http://www.matrixlist.com/pipermail/harbour/2007-October/004290.html
> I was working with a DBF file that had this and caused dbfpy to fail.
> The typeCode for _nullFlags is 0 (zero), so I tied adding a news class
> to fields.py with the same properties as the class
> "DbfCharacterFieldDef", with the exception of the typeCode. That seemed
> to fix it, at least for the file I was working with.

thank you for bringing the issue to attention.

however, true support for nullable and/or variable length fields would 
require more than simple ignoring of the flag bits.

> class DbfNullFlagsFieldDef(DbfFieldDef):
> """Definition of the _nullFlags field."""
>
>      typeCode = "0"
>      defaultValue = ""
>
>      def decodeValue(self, value):
> """Return string object.
>
>          Return value is a ``value`` argument with stripped right spaces.
>
> """
>          return value.rstrip(" ")
>
>      def encodeValue(self, value):
> """Return raw data string encoded from a ``value``."""
>          return str(value)[:self.length].ljust(self.length)

i am sorry, stripping or padding with spaces do not look like a sensible 
operations for bit masks stored in the null flags field.

besides, i think that the flags should be somehow handled at the record 
level and not as an extra field in a record, totally unrelated to the 
fields that are flagged by the null/variable length bits.

best wishes,
alex.