Reading Dbase files

[John Machin]

Robert Amesz <sheershion at mailexpire.com> wrote in message news:<Xns920C9B6079352rcamesz at amesz.demon.nl>...
> Leo Noordhuizen wrote:
> 
> > I am trying to read .dbf files using the (old) dbf.py module
> > (version 0.2 1999/11/12 written
> > by Michal Spalinski. This seemed to work quite well, untill I
> > found out that records which apparantly
> > have been deleted are also read as 'normal'...

How did you find out? What do the apparently-deleted records look
like? Rhetorical question, answer supplied below, I'm just eternally
curious about
the way humans diagnose problems :-)

> > In other words: not really useable or at least not compatible with
> > this format of .dbf files.
> > 
> > I am looking for advise how to proceed. I really need this
> > functionality and should like to keep on using Python.
> 
> I'm not familiar with dbf.py, but old dBase programs don't physically 
> delete the record (not right away, anyway) but set a marker in a 
> special field to indicate their deleted status. I presume there's some 
> way in which this marker can be tested in dbf.py, and if not it 
> shouldn't be terribly hard to add this. The dBase file format is well 
> documented over the years.
>

Here is the relevant part from dbf.py:

    def __getitem__(self, recno):
	if recno < 0 or recno >= self.nrecs:
	    raise IndexError
	else:
	    raw = self._get(recno) 

A deleted record will satisfy raw[0] == '*'

Here is one of the places where you discover such knowledge:

    http://www.wotsit.org/

You might want to add a sequential-reading method to the dbf class, as
well as or instead of hacking in raising a DeletedRecordError (or
somesuch) exception in the __getitem__ method. You may even be
interested in recovering the deleted records after a disaster. If
fiddling with dbf.py along those lines is not your territory, e-mail
me -- I have such a sequentially-reading gadget written circa 1999; it
will even run with Python 1.5.2.

HTH,

John