dbfpy-devel

[dbfpy-devel] memo field fix [patch]

[Zeljko S. <zs...@gm...>]

Hi.

I discovered small problem with formatting memo field.  Patch attached.

Tested with harbour files, but only reading.

regards,
zeljko

Re: [dbfpy-devel] Bug #16

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

On 21.10.2014 12:39, Yevgen Antymyrov wrote:
>
> I've prepared a fix for bug #16 (https://sourceforge.net/p/dbfpy/bugs/16/)
>
> Now, how can i check it in?

I have verified the bug and the fix and checked in the fix.  Thank you 
very much!

Best wishes,
alex.

[dbfpy-devel] Bug #16

[Yevgen A. <yev...@an...>]

Hi guys,

I've prepared a fix for bug #16 (https://sourceforge.net/p/dbfpy/bugs/16/)

$ bzr diff -c 84
=== modified file 'dbfpy/dbf.py'
--- dbfpy/dbf.py    2012-12-17 19:16:57 +0000
+++ dbfpy/dbf.py    2014-10-21 09:17:44 +0000
@@ -208,7 +208,8 @@
              self.header.setCurrentDate()
              self.header.write(self.stream)
              self.stream.flush()
-            self.memo.flush()
+            if self.memo:
+                self.memo.flush()
              self._changed = False

      def indexOfFieldName(self, name):


Now, how can i check it in? I tried 'bzr push', but, surely, got "Permission denied".

-- 
Yevgen

[dbfpy-devel] Python3 ?

[Helmut J. <jar...@ig...>]

Hi,

has anybody tried to port dbfpy to Python3?

Thanks for hint,
Helmut.

[dbfpy-devel] [ dbfpy-Bugs-3560359 ] dbfpy does not handle NaN or Infinity value in dbf files

[SourceForge.net <no...@so...>]

Bugs item #3560359, was opened at 2012-08-21 07:03
Message generated for change (Comment added) made by a1s
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=746843&aid=3560359&group_id=140566

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: Reuter (gisxperts)
Assigned to: Nobody/Anonymous (nobody)
Summary: dbfpy  does not handle NaN or Infinity value in dbf files

Initial Comment:
db = dbf.Dbf(infile, new=False)
[Dbg]>>> rec=db[0]
Traceback (most recent call last):
  File "<interactive input>", line 1, in <module>
  File "C:\Python26\ArcGIS10.0\lib\site-packages\dbfpy\dbf.py", line 242, in __getitem__
    return self.RecordClass.fromStream(self, self._fixIndex(index))
  File "C:\Python26\ArcGIS10.0\lib\site-packages\dbfpy\record.py", line 121, in fromStream
    return cls.fromString(dbf, cls.rawFromStream(dbf, index), index)
  File "C:\Python26\ArcGIS10.0\lib\site-packages\dbfpy\record.py", line 140, in fromString
    [_fd.decodeFromRecord(string) for _fd in dbf.header.fields])
  File "C:\Python26\ArcGIS10.0\lib\site-packages\dbfpy\fields.py", line 173, in decodeFromRecord
    return self.decodeValue(self.rawFromRecord(record))
  File "C:\Python26\ArcGIS10.0\lib\site-packages\dbfpy\fields.py", line 241, in decodeValue
    return float(value)
ValueError: invalid literal for float(): -1.#IND00000000000

----------------------------------------------------------------------

>Comment By: alexander smishlajev (a1s)
Date: 2012-08-29 01:02

Message:
So, these files are not produced by xBase software - dBase, FoxPro, Clipper
or some such.

Futhermore, formatting is not what one would expect (see f.e.
http://en.wikipedia.org/wiki/Printf_format_string): 'nan' for IEEE 754 NaN
and 'inf' for infinity.

GeoTIFF stores numbers in binary format, so the formatting behaviour is set
up in the extraction software.  Perhaps you could talk to authors of that
software.

As for dbfpy, I am resistant to amend base functionality for non-standard
uses.  Instead, I recommend subclassing DbfNumericFieldDef in your
application.  (Call registerField() to install customized field class.)

Closing this issue for now; please reopen if you see reasons to reconsider.

----------------------------------------------------------------------

Comment By: Reuter (gisxperts)
Date: 2012-08-28 15:52

Message:
python libraries linking GDAL extracted values from TIF files was able to
write these values into dbf. no real documentation, but observed values. 


----------------------------------------------------------------------

Comment By: alexander smishlajev (a1s)
Date: 2012-08-21 09:14

Message:
Thank you for reporting this.

Could you point to documentation describing storage format for these
values?

----------------------------------------------------------------------

Comment By: Reuter (gisxperts)
Date: 2012-08-21 07:59

Message:
Patch for the problem extend the lines in field.py line 228ff. however a
cleaner solution would be better. 

     def decodeValue(self, value):
        """Return a number decoded from ``value``.

        If decimals is zero, value will be decoded as an integer;
        or as a float otherwise.

        Return:
            Return value is a int (long) or float instance.

        """
        value = value.strip(" \0")
        if "." in value:
            # a float (has decimal separator)
            if '#IND' in value:
                return(-9999.9999)
            elif '#QNAN' in value:
                return(-9999.9999)
            else:
                return float(value)
        elif '*' in value:
                return(-9999.9999)
        elif value:
            # must be an integer
            return int(value)
        else:
            return 0

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=746843&aid=3560359&group_id=140566

[dbfpy-devel] [ dbfpy-Bugs-3560359 ] dbfpy does not handle NaN or Infinity value in dbf files

[SourceForge.net <no...@so...>]

Bugs item #3560359, was opened at 2012-08-21 07:03
Message generated for change (Comment added) made by gisxperts
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=746843&aid=3560359&group_id=140566

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Reuter (gisxperts)
Assigned to: Nobody/Anonymous (nobody)
Summary: dbfpy  does not handle NaN or Infinity value in dbf files

Initial Comment:
db = dbf.Dbf(infile, new=False)
[Dbg]>>> rec=db[0]
Traceback (most recent call last):
  File "<interactive input>", line 1, in <module>
  File "C:\Python26\ArcGIS10.0\lib\site-packages\dbfpy\dbf.py", line 242, in __getitem__
    return self.RecordClass.fromStream(self, self._fixIndex(index))
  File "C:\Python26\ArcGIS10.0\lib\site-packages\dbfpy\record.py", line 121, in fromStream
    return cls.fromString(dbf, cls.rawFromStream(dbf, index), index)
  File "C:\Python26\ArcGIS10.0\lib\site-packages\dbfpy\record.py", line 140, in fromString
    [_fd.decodeFromRecord(string) for _fd in dbf.header.fields])
  File "C:\Python26\ArcGIS10.0\lib\site-packages\dbfpy\fields.py", line 173, in decodeFromRecord
    return self.decodeValue(self.rawFromRecord(record))
  File "C:\Python26\ArcGIS10.0\lib\site-packages\dbfpy\fields.py", line 241, in decodeValue
    return float(value)
ValueError: invalid literal for float(): -1.#IND00000000000

----------------------------------------------------------------------

>Comment By: Reuter (gisxperts)
Date: 2012-08-28 15:52

Message:
python libraries linking GDAL extracted values from TIF files was able to
write these values into dbf. no real documentation, but observed values. 


----------------------------------------------------------------------

Comment By: alexander smishlajev (a1s)
Date: 2012-08-21 09:14

Message:
Thank you for reporting this.

Could you point to documentation describing storage format for these
values?

----------------------------------------------------------------------

Comment By: Reuter (gisxperts)
Date: 2012-08-21 07:59

Message:
Patch for the problem extend the lines in field.py line 228ff. however a
cleaner solution would be better. 

     def decodeValue(self, value):
        """Return a number decoded from ``value``.

        If decimals is zero, value will be decoded as an integer;
        or as a float otherwise.

        Return:
            Return value is a int (long) or float instance.

        """
        value = value.strip(" \0")
        if "." in value:
            # a float (has decimal separator)
            if '#IND' in value:
                return(-9999.9999)
            elif '#QNAN' in value:
                return(-9999.9999)
            else:
                return float(value)
        elif '*' in value:
                return(-9999.9999)
        elif value:
            # must be an integer
            return int(value)
        else:
            return 0

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=746843&aid=3560359&group_id=140566

[dbfpy-devel] [ dbfpy-Bugs-3560359 ] dbfpy does not handle NaN or Infinity value in dbf files

[SourceForge.net <no...@so...>]

Bugs item #3560359, was opened at 2012-08-21 07:03
Message generated for change (Comment added) made by a1s
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=746843&aid=3560359&group_id=140566

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Reuter (gisxperts)
Assigned to: Nobody/Anonymous (nobody)
Summary: dbfpy  does not handle NaN or Infinity value in dbf files

Initial Comment:
db = dbf.Dbf(infile, new=False)
[Dbg]>>> rec=db[0]
Traceback (most recent call last):
  File "<interactive input>", line 1, in <module>
  File "C:\Python26\ArcGIS10.0\lib\site-packages\dbfpy\dbf.py", line 242, in __getitem__
    return self.RecordClass.fromStream(self, self._fixIndex(index))
  File "C:\Python26\ArcGIS10.0\lib\site-packages\dbfpy\record.py", line 121, in fromStream
    return cls.fromString(dbf, cls.rawFromStream(dbf, index), index)
  File "C:\Python26\ArcGIS10.0\lib\site-packages\dbfpy\record.py", line 140, in fromString
    [_fd.decodeFromRecord(string) for _fd in dbf.header.fields])
  File "C:\Python26\ArcGIS10.0\lib\site-packages\dbfpy\fields.py", line 173, in decodeFromRecord
    return self.decodeValue(self.rawFromRecord(record))
  File "C:\Python26\ArcGIS10.0\lib\site-packages\dbfpy\fields.py", line 241, in decodeValue
    return float(value)
ValueError: invalid literal for float(): -1.#IND00000000000

----------------------------------------------------------------------

>Comment By: alexander smishlajev (a1s)
Date: 2012-08-21 09:14

Message:
Thank you for reporting this.

Could you point to documentation describing storage format for these
values?

----------------------------------------------------------------------

Comment By: Reuter (gisxperts)
Date: 2012-08-21 07:59

Message:
Patch for the problem extend the lines in field.py line 228ff. however a
cleaner solution would be better. 

     def decodeValue(self, value):
        """Return a number decoded from ``value``.

        If decimals is zero, value will be decoded as an integer;
        or as a float otherwise.

        Return:
            Return value is a int (long) or float instance.

        """
        value = value.strip(" \0")
        if "." in value:
            # a float (has decimal separator)
            if '#IND' in value:
                return(-9999.9999)
            elif '#QNAN' in value:
                return(-9999.9999)
            else:
                return float(value)
        elif '*' in value:
                return(-9999.9999)
        elif value:
            # must be an integer
            return int(value)
        else:
            return 0

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=746843&aid=3560359&group_id=140566

[dbfpy-devel] [ dbfpy-Bugs-3560359 ] dbfpy does not handle NaN or Infinity value in dbf files

[SourceForge.net <no...@so...>]

Bugs item #3560359, was opened at 2012-08-21 07:03
Message generated for change (Comment added) made by gisxperts
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=746843&aid=3560359&group_id=140566

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Reuter (gisxperts)
Assigned to: Nobody/Anonymous (nobody)
Summary: dbfpy  does not handle NaN or Infinity value in dbf files

Initial Comment:
db = dbf.Dbf(infile, new=False)
[Dbg]>>> rec=db[0]
Traceback (most recent call last):
  File "<interactive input>", line 1, in <module>
  File "C:\Python26\ArcGIS10.0\lib\site-packages\dbfpy\dbf.py", line 242, in __getitem__
    return self.RecordClass.fromStream(self, self._fixIndex(index))
  File "C:\Python26\ArcGIS10.0\lib\site-packages\dbfpy\record.py", line 121, in fromStream
    return cls.fromString(dbf, cls.rawFromStream(dbf, index), index)
  File "C:\Python26\ArcGIS10.0\lib\site-packages\dbfpy\record.py", line 140, in fromString
    [_fd.decodeFromRecord(string) for _fd in dbf.header.fields])
  File "C:\Python26\ArcGIS10.0\lib\site-packages\dbfpy\fields.py", line 173, in decodeFromRecord
    return self.decodeValue(self.rawFromRecord(record))
  File "C:\Python26\ArcGIS10.0\lib\site-packages\dbfpy\fields.py", line 241, in decodeValue
    return float(value)
ValueError: invalid literal for float(): -1.#IND00000000000

----------------------------------------------------------------------

>Comment By: Reuter (gisxperts)
Date: 2012-08-21 07:59

Message:
Patch for the problem extend the lines in field.py line 228ff. however a
cleaner solution would be better. 

     def decodeValue(self, value):
        """Return a number decoded from ``value``.

        If decimals is zero, value will be decoded as an integer;
        or as a float otherwise.

        Return:
            Return value is a int (long) or float instance.

        """
        value = value.strip(" \0")
        if "." in value:
            # a float (has decimal separator)
            if '#IND' in value:
                return(-9999.9999)
            elif '#QNAN' in value:
                return(-9999.9999)
            else:
                return float(value)
        elif '*' in value:
                return(-9999.9999)
        elif value:
            # must be an integer
            return int(value)
        else:
            return 0

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=746843&aid=3560359&group_id=140566

[dbfpy-devel] [ dbfpy-Bugs-3560359 ] dbfpy does not handle NaN or Infinity value in dbf files

[SourceForge.net <no...@so...>]

Bugs item #3560359, was opened at 2012-08-21 07:03
Message generated for change (Tracker Item Submitted) made by gisxperts
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=746843&aid=3560359&group_id=140566

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Reuter (gisxperts)
Assigned to: Nobody/Anonymous (nobody)
Summary: dbfpy  does not handle NaN or Infinity value in dbf files

Initial Comment:
db = dbf.Dbf(infile, new=False)
[Dbg]>>> rec=db[0]
Traceback (most recent call last):
  File "<interactive input>", line 1, in <module>
  File "C:\Python26\ArcGIS10.0\lib\site-packages\dbfpy\dbf.py", line 242, in __getitem__
    return self.RecordClass.fromStream(self, self._fixIndex(index))
  File "C:\Python26\ArcGIS10.0\lib\site-packages\dbfpy\record.py", line 121, in fromStream
    return cls.fromString(dbf, cls.rawFromStream(dbf, index), index)
  File "C:\Python26\ArcGIS10.0\lib\site-packages\dbfpy\record.py", line 140, in fromString
    [_fd.decodeFromRecord(string) for _fd in dbf.header.fields])
  File "C:\Python26\ArcGIS10.0\lib\site-packages\dbfpy\fields.py", line 173, in decodeFromRecord
    return self.decodeValue(self.rawFromRecord(record))
  File "C:\Python26\ArcGIS10.0\lib\site-packages\dbfpy\fields.py", line 241, in decodeValue
    return float(value)
ValueError: invalid literal for float(): -1.#IND00000000000

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=746843&aid=3560359&group_id=140566

[dbfpy-devel] [ dbfpy-Bugs-3391899 ] Error description

[SourceForge.net <no...@so...>]

Bugs item #3391899, was opened at 2011-08-15 15:14
Message generated for change (Comment added) made by a1s
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=746843&aid=3391899&group_id=140566

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Roland B*atz (styriker)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error description

Initial Comment:
Hi,
I'm using dbipy and thank you for creating it! It is very helpful!
I encountered one wrong error message when I wanted to open the file even though it was not closed before.
Maybe it could help modifying the error message to trace down that the file was not closed before.
The error message I got was the following:


Traceback (most recent call last):
  File "dbfP1.py", line 225, in <module>
    newDBF =  dbf.Dbf("new.dbf")
  File "/usr/local/lib/python2.7/dist-packages/dbfpy/dbf.py", line 135, in __init__
    self.header = self.HeaderClass.fromStream(self.stream)
  File "/usr/local/lib/python2.7/dist-packages/dbfpy/header.py", line 120, in fromStream
    (_year, ord(_data[2]), ord(_data[3])))
  File "/usr/local/lib/python2.7/dist-packages/dbfpy/header.py", line 89, in __init__
    self.lastUpdate = getDate(lastUpdate)
  File "/usr/local/lib/python2.7/dist-packages/dbfpy/utils.py", line 75, in getDate
    return datetime.date(*date[:3])
ValueError: month must be in 1..12

Well, thanks for considering my request.
I'm just a newbie in python, so sorry for additional work.

Best regards,
Roland

----------------------------------------------------------------------

>Comment By: alexander smishlajev (a1s)
Date: 2011-08-15 18:12

Message:
You have to do dbOut.close() after "for rec in dbIn" loop.

----------------------------------------------------------------------

Comment By: Roland B*atz (styriker)
Date: 2011-08-15 16:57

Message:
Hi Alex,

thank you for your quick response!
I attached the dbf used and the python code.
In fact I made the file myself. I did not consider using a header so far.
The dbf is part of a shapefile.
Roland

----------------------------------------------------------------------

Comment By: alexander smishlajev (a1s)
Date: 2011-08-15 16:20

Message:
Your dbf file seems to have invalid header.  If the file is produced by one
of the xBases (such as dBase, Clipper or FoxPro), please provide the file
itself and tell how did you make this dbf.

If the file was made by some other software, please contact the vendor of
that software.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=746843&aid=3391899&group_id=140566

[dbfpy-devel] [ dbfpy-Bugs-3391899 ] Error description

[SourceForge.net <no...@so...>]

Bugs item #3391899, was opened at 2011-08-15 14:14
Message generated for change (Comment added) made by styriker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=746843&aid=3391899&group_id=140566

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Open
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Roland B*atz (styriker)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error description

Initial Comment:
Hi,
I'm using dbipy and thank you for creating it! It is very helpful!
I encountered one wrong error message when I wanted to open the file even though it was not closed before.
Maybe it could help modifying the error message to trace down that the file was not closed before.
The error message I got was the following:


Traceback (most recent call last):
  File "dbfP1.py", line 225, in <module>
    newDBF =  dbf.Dbf("new.dbf")
  File "/usr/local/lib/python2.7/dist-packages/dbfpy/dbf.py", line 135, in __init__
    self.header = self.HeaderClass.fromStream(self.stream)
  File "/usr/local/lib/python2.7/dist-packages/dbfpy/header.py", line 120, in fromStream
    (_year, ord(_data[2]), ord(_data[3])))
  File "/usr/local/lib/python2.7/dist-packages/dbfpy/header.py", line 89, in __init__
    self.lastUpdate = getDate(lastUpdate)
  File "/usr/local/lib/python2.7/dist-packages/dbfpy/utils.py", line 75, in getDate
    return datetime.date(*date[:3])
ValueError: month must be in 1..12

Well, thanks for considering my request.
I'm just a newbie in python, so sorry for additional work.

Best regards,
Roland

----------------------------------------------------------------------

>Comment By: Roland B*atz (styriker)
Date: 2011-08-15 15:57

Message:
Hi Alex,

thank you for your quick response!
I attached the dbf used and the python code.
In fact I made the file myself. I did not consider using a header so far.
The dbf is part of a shapefile.
Roland

----------------------------------------------------------------------

Comment By: alexander smishlajev (a1s)
Date: 2011-08-15 15:20

Message:
Your dbf file seems to have invalid header.  If the file is produced by one
of the xBases (such as dBase, Clipper or FoxPro), please provide the file
itself and tell how did you make this dbf.

If the file was made by some other software, please contact the vendor of
that software.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=746843&aid=3391899&group_id=140566

[dbfpy-devel] [ dbfpy-Bugs-3391899 ] Error description

[SourceForge.net <no...@so...>]

Bugs item #3391899, was opened at 2011-08-15 15:14
Message generated for change (Comment added) made by a1s
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=746843&aid=3391899&group_id=140566

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Pending
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Roland B*atz (styriker)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error description

Initial Comment:
Hi,
I'm using dbipy and thank you for creating it! It is very helpful!
I encountered one wrong error message when I wanted to open the file even though it was not closed before.
Maybe it could help modifying the error message to trace down that the file was not closed before.
The error message I got was the following:


Traceback (most recent call last):
  File "dbfP1.py", line 225, in <module>
    newDBF =  dbf.Dbf("new.dbf")
  File "/usr/local/lib/python2.7/dist-packages/dbfpy/dbf.py", line 135, in __init__
    self.header = self.HeaderClass.fromStream(self.stream)
  File "/usr/local/lib/python2.7/dist-packages/dbfpy/header.py", line 120, in fromStream
    (_year, ord(_data[2]), ord(_data[3])))
  File "/usr/local/lib/python2.7/dist-packages/dbfpy/header.py", line 89, in __init__
    self.lastUpdate = getDate(lastUpdate)
  File "/usr/local/lib/python2.7/dist-packages/dbfpy/utils.py", line 75, in getDate
    return datetime.date(*date[:3])
ValueError: month must be in 1..12

Well, thanks for considering my request.
I'm just a newbie in python, so sorry for additional work.

Best regards,
Roland

----------------------------------------------------------------------

>Comment By: alexander smishlajev (a1s)
Date: 2011-08-15 16:20

Message:
Your dbf file seems to have invalid header.  If the file is produced by one
of the xBases (such as dBase, Clipper or FoxPro), please provide the file
itself and tell how did you make this dbf.

If the file was made by some other software, please contact the vendor of
that software.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=746843&aid=3391899&group_id=140566

[dbfpy-devel] [ dbfpy-Bugs-3391899 ] Error description

[SourceForge.net <no...@so...>]

Bugs item #3391899, was opened at 2011-08-15 14:14
Message generated for change (Tracker Item Submitted) made by styriker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=746843&aid=3391899&group_id=140566

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Roland B*atz (styriker)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error description

Initial Comment:
Hi,
I'm using dbipy and thank you for creating it! It is very helpful!
I encountered one wrong error message when I wanted to open the file even though it was not closed before.
Maybe it could help modifying the error message to trace down that the file was not closed before.
The error message I got was the following:


Traceback (most recent call last):
  File "dbfP1.py", line 225, in <module>
    newDBF =  dbf.Dbf("new.dbf")
  File "/usr/local/lib/python2.7/dist-packages/dbfpy/dbf.py", line 135, in __init__
    self.header = self.HeaderClass.fromStream(self.stream)
  File "/usr/local/lib/python2.7/dist-packages/dbfpy/header.py", line 120, in fromStream
    (_year, ord(_data[2]), ord(_data[3])))
  File "/usr/local/lib/python2.7/dist-packages/dbfpy/header.py", line 89, in __init__
    self.lastUpdate = getDate(lastUpdate)
  File "/usr/local/lib/python2.7/dist-packages/dbfpy/utils.py", line 75, in getDate
    return datetime.date(*date[:3])
ValueError: month must be in 1..12

Well, thanks for considering my request.
I'm just a newbie in python, so sorry for additional work.

Best regards,
Roland

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=746843&aid=3391899&group_id=140566

[dbfpy-devel] [ dbfpy-Bugs-3380181 ] Method isDeleted on linux

[SourceForge.net <no...@so...>]

Bugs item #3380181, was opened at 2011-07-27 22:23
Message generated for change (Tracker Item Submitted) made by tyvik8
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=746843&aid=3380181&group_id=140566

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: TyVik (tyvik8)
Assigned to: Nobody/Anonymous (nobody)
Summary: Method isDeleted on linux

Initial Comment:
Method isDeleted already return False. I look at source and replace 
self.isDeleted = (rawDataString[0]=='0x2A')  #del='*'  notDel=' '
on
self.isDeleted = (rawDataString[0]==u'*')  #del='*'  notDel=' '
works, but I think it's not a good idea. Can you fix this bug? My OS is openSUSE 11.3, python 2.6.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=746843&aid=3380181&group_id=140566

[dbfpy-devel] DBF 2 Sqlite

[Sunil M. R. <sm...@sm...>]

Here is a simple program to convert DBFs to Sqlite using dbfpy

And thanks for the good work on dbfpy. Reading dbfpy would have been a pain
otherwise.

[dbfpy-devel] [ dbfpy-Feature Requests-3135344 ] Read FPT files

[SourceForge.net <no...@so...>]

Feature Requests item #3135344, was opened at 2010-12-12 01:15
Message generated for change (Comment added) made by a1s
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=746846&aid=3135344&group_id=140566

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Cristian Sebastian Rocha (csrocha)
Assigned to: Nobody/Anonymous (nobody)
Summary: Read FPT files

Initial Comment:
Hello,

I've been adding code to allow reading files FPT. Here I attached the diff. To use it you just have to start the Dbf object as follows:

table = dbf.Dbf (dbf_filename, fpt_file = open ('table.FPT'))

The only problem I can bring problem is if the file block size is different to 64. There needs to be altered set_ftp function.

----------------------------------------------------------------------

>Comment By: alexander smishlajev (a1s)
Date: 2010-12-13 09:33

Message:
from your code i understand that the first data block in memo file with
blocksize 64 has number 9.  is that correct?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=746846&aid=3135344&group_id=140566

[dbfpy-devel] [ dbfpy-Feature Requests-3135344 ] Read FPT files

[SourceForge.net <no...@so...>]

Feature Requests item #3135344, was opened at 2010-12-11 20:15
Message generated for change (Tracker Item Submitted) made by csrocha
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=746846&aid=3135344&group_id=140566

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Cristian Sebastian Rocha (csrocha)
Assigned to: Nobody/Anonymous (nobody)
Summary: Read FPT files

Initial Comment:
Hello,

I've been adding code to allow reading files FPT. Here I attached the diff. To use it you just have to start the Dbf object as follows:

table = dbf.Dbf (dbf_filename, fpt_file = open ('table.FPT'))

The only problem I can bring problem is if the file block size is different to 64. There needs to be altered set_ftp function.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=746846&aid=3135344&group_id=140566

[dbfpy-devel] [ dbfpy-Bugs-3065838 ] Y2K problem proving

[SourceForge.net <no...@so...>]

Bugs item #3065838, was opened at 2010-09-14 12:36
Message generated for change (Comment added) made by a1s
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=746843&aid=3065838&group_id=140566

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: jno (jno-)
Assigned to: Nobody/Anonymous (nobody)
Summary: Y2K problem proving

Initial Comment:
I have a government-provided (read as "unfixable") application (sample DBF is attached) where anyone can see year "1909" using the module.
I afraid, that two-digit wrapping is NOT performed by time.strptime in 2.6.5.

----------------------------------------------------------------------

>Comment By: alexander smishlajev (a1s)
Date: 2010-09-16 08:07

Message:
fixed in cvs

----------------------------------------------------------------------

Comment By: jno (jno-)
Date: 2010-09-15 21:22

Message:
Sorry for being unclear :(

----------------------------------------------------------------------

Comment By: alexander smishlajev (a1s)
Date: 2010-09-15 20:55

Message:
ah!  why didn't you say that the problem is with the DBF header?  i would
never guessed: i use OS file timestamps for that purposes.

well, according to specs the interval for the last update field is
1900-2155.  but i agree that y2k-folding may be done around year 70 there.

----------------------------------------------------------------------

Comment By: jno (jno-)
Date: 2010-09-15 15:35

Message:
from dbfpy import dbf
db = dbf.Dbf('SOCRBASE.DBF')
print db.header
# this code gives me:
Version (signature): 0x03
        Last update: 1909-08-25
      Header length: 161
      Record length: 48
       Record count: 143
 FieldName Type Len Dec
     LEVEL    C   5   0
    SCNAME    C  10   0
  SOCRNAME    C  29   0
  KOD_T_ST    C   3   0


----------------------------------------------------------------------

Comment By: alexander smishlajev (a1s)
Date: 2010-09-15 07:19

Message:
> sample DBF is attached) where anyone can see year "1909" using the
module.

the attached file contains neither date nor datetime fields.

> I afraid, that two-digit wrapping is NOT performed by time.strptime in
2.6.5.

Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.strptime("090807", "%y%m%d")
time.struct_time(tm_year=2009, tm_mon=8, tm_mday=7, tm_hour=0, tm_min=0,
tm_sec=0, tm_wday=4, tm_yday=219, tm_isdst=-1)
>>>


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=746843&aid=3065838&group_id=140566

[dbfpy-devel] [ dbfpy-Bugs-3065838 ] Y2K problem proving

[SourceForge.net <no...@so...>]

Bugs item #3065838, was opened at 2010-09-14 13:36
Message generated for change (Comment added) made by jno-
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=746843&aid=3065838&group_id=140566

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: jno (jno-)
Assigned to: Nobody/Anonymous (nobody)
Summary: Y2K problem proving

Initial Comment:
I have a government-provided (read as "unfixable") application (sample DBF is attached) where anyone can see year "1909" using the module.
I afraid, that two-digit wrapping is NOT performed by time.strptime in 2.6.5.

----------------------------------------------------------------------

>Comment By: jno (jno-)
Date: 2010-09-15 22:22

Message:
Sorry for being unclear :(

----------------------------------------------------------------------

Comment By: alexander smishlajev (a1s)
Date: 2010-09-15 21:55

Message:
ah!  why didn't you say that the problem is with the DBF header?  i would
never guessed: i use OS file timestamps for that purposes.

well, according to specs the interval for the last update field is
1900-2155.  but i agree that y2k-folding may be done around year 70 there.

----------------------------------------------------------------------

Comment By: jno (jno-)
Date: 2010-09-15 16:35

Message:
from dbfpy import dbf
db = dbf.Dbf('SOCRBASE.DBF')
print db.header
# this code gives me:
Version (signature): 0x03
        Last update: 1909-08-25
      Header length: 161
      Record length: 48
       Record count: 143
 FieldName Type Len Dec
     LEVEL    C   5   0
    SCNAME    C  10   0
  SOCRNAME    C  29   0
  KOD_T_ST    C   3   0


----------------------------------------------------------------------

Comment By: alexander smishlajev (a1s)
Date: 2010-09-15 08:19

Message:
> sample DBF is attached) where anyone can see year "1909" using the
module.

the attached file contains neither date nor datetime fields.

> I afraid, that two-digit wrapping is NOT performed by time.strptime in
2.6.5.

Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.strptime("090807", "%y%m%d")
time.struct_time(tm_year=2009, tm_mon=8, tm_mday=7, tm_hour=0, tm_min=0,
tm_sec=0, tm_wday=4, tm_yday=219, tm_isdst=-1)
>>>


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=746843&aid=3065838&group_id=140566

[dbfpy-devel] [ dbfpy-Bugs-3065838 ] Y2K problem proving

[SourceForge.net <no...@so...>]

Bugs item #3065838, was opened at 2010-09-14 12:36
Message generated for change (Comment added) made by a1s
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=746843&aid=3065838&group_id=140566

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: jno (jno-)
Assigned to: Nobody/Anonymous (nobody)
Summary: Y2K problem proving

Initial Comment:
I have a government-provided (read as "unfixable") application (sample DBF is attached) where anyone can see year "1909" using the module.
I afraid, that two-digit wrapping is NOT performed by time.strptime in 2.6.5.

----------------------------------------------------------------------

>Comment By: alexander smishlajev (a1s)
Date: 2010-09-15 20:55

Message:
ah!  why didn't you say that the problem is with the DBF header?  i would
never guessed: i use OS file timestamps for that purposes.

well, according to specs the interval for the last update field is
1900-2155.  but i agree that y2k-folding may be done around year 70 there.

----------------------------------------------------------------------

Comment By: jno (jno-)
Date: 2010-09-15 15:35

Message:
from dbfpy import dbf
db = dbf.Dbf('SOCRBASE.DBF')
print db.header
# this code gives me:
Version (signature): 0x03
        Last update: 1909-08-25
      Header length: 161
      Record length: 48
       Record count: 143
 FieldName Type Len Dec
     LEVEL    C   5   0
    SCNAME    C  10   0
  SOCRNAME    C  29   0
  KOD_T_ST    C   3   0


----------------------------------------------------------------------

Comment By: alexander smishlajev (a1s)
Date: 2010-09-15 07:19

Message:
> sample DBF is attached) where anyone can see year "1909" using the
module.

the attached file contains neither date nor datetime fields.

> I afraid, that two-digit wrapping is NOT performed by time.strptime in
2.6.5.

Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.strptime("090807", "%y%m%d")
time.struct_time(tm_year=2009, tm_mon=8, tm_mday=7, tm_hour=0, tm_min=0,
tm_sec=0, tm_wday=4, tm_yday=219, tm_isdst=-1)
>>>


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=746843&aid=3065838&group_id=140566

[dbfpy-devel] [ dbfpy-Bugs-3065838 ] Y2K problem proving

[SourceForge.net <no...@so...>]

Bugs item #3065838, was opened at 2010-09-14 13:36
Message generated for change (Settings changed) made by jno-
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=746843&aid=3065838&group_id=140566

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: jno (jno-)
Assigned to: Nobody/Anonymous (nobody)
Summary: Y2K problem proving

Initial Comment:
I have a government-provided (read as "unfixable") application (sample DBF is attached) where anyone can see year "1909" using the module.
I afraid, that two-digit wrapping is NOT performed by time.strptime in 2.6.5.

----------------------------------------------------------------------

>Comment By: jno (jno-)
Date: 2010-09-15 16:35

Message:
from dbfpy import dbf
db = dbf.Dbf('SOCRBASE.DBF')
print db.header
# this code gives me:
Version (signature): 0x03
        Last update: 1909-08-25
      Header length: 161
      Record length: 48
       Record count: 143
 FieldName Type Len Dec
     LEVEL    C   5   0
    SCNAME    C  10   0
  SOCRNAME    C  29   0
  KOD_T_ST    C   3   0


----------------------------------------------------------------------

Comment By: alexander smishlajev (a1s)
Date: 2010-09-15 08:19

Message:
> sample DBF is attached) where anyone can see year "1909" using the
module.

the attached file contains neither date nor datetime fields.

> I afraid, that two-digit wrapping is NOT performed by time.strptime in
2.6.5.

Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.strptime("090807", "%y%m%d")
time.struct_time(tm_year=2009, tm_mon=8, tm_mday=7, tm_hour=0, tm_min=0,
tm_sec=0, tm_wday=4, tm_yday=219, tm_isdst=-1)
>>>


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=746843&aid=3065838&group_id=140566

[dbfpy-devel] [ dbfpy-Bugs-3065838 ] Y2K problem proving

[SourceForge.net <no...@so...>]

Bugs item #3065838, was opened at 2010-09-14 12:36
Message generated for change (Settings changed) made by a1s
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=746843&aid=3065838&group_id=140566

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Pending
Resolution: None
Priority: 5
Private: No
Submitted By: jno (jno-)
Assigned to: Nobody/Anonymous (nobody)
Summary: Y2K problem proving

Initial Comment:
I have a government-provided (read as "unfixable") application (sample DBF is attached) where anyone can see year "1909" using the module.
I afraid, that two-digit wrapping is NOT performed by time.strptime in 2.6.5.

----------------------------------------------------------------------

>Comment By: alexander smishlajev (a1s)
Date: 2010-09-15 07:19

Message:
> sample DBF is attached) where anyone can see year "1909" using the
module.

the attached file contains neither date nor datetime fields.

> I afraid, that two-digit wrapping is NOT performed by time.strptime in
2.6.5.

Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.strptime("090807", "%y%m%d")
time.struct_time(tm_year=2009, tm_mon=8, tm_mday=7, tm_hour=0, tm_min=0,
tm_sec=0, tm_wday=4, tm_yday=219, tm_isdst=-1)
>>>


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=746843&aid=3065838&group_id=140566

[dbfpy-devel] [ dbfpy-Bugs-3065838 ] Y2K problem proving

[SourceForge.net <no...@so...>]

Bugs item #3065838, was opened at 2010-09-14 13:36
Message generated for change (Tracker Item Submitted) made by jno-
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=746843&aid=3065838&group_id=140566

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: jno (jno-)
Assigned to: Nobody/Anonymous (nobody)
Summary: Y2K problem proving

Initial Comment:
I have a government-provided (read as "unfixable") application (sample DBF is attached) where anyone can see year "1909" using the module.
I afraid, that two-digit wrapping is NOT performed by time.strptime in 2.6.5.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=746843&aid=3065838&group_id=140566

[dbfpy-devel] [ dbfpy-Bugs-3065292 ] y2k fix proposed

[SourceForge.net <no...@so...>]

Bugs item #3065292, was opened at 2010-09-13 16:32
Message generated for change (Comment added) made by a1s
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=746843&aid=3065292&group_id=140566

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: jno (jno-)
Assigned to: Nobody/Anonymous (nobody)
Summary: y2k fix proposed

Initial Comment:
Some applications still use DBF. This is a matter of fact.
But the DBF is not supposed to handle Y2K+ dates. But it does.
But the dbfpy cannot handle them. But it should.
So, I propose a [incomplete] fix to utils.getDate().

----------------------------------------------------------------------

>Comment By: alexander smishlajev (a1s)
Date: 2010-09-13 21:33

Message:
first, DBF is perfectly capable of handling dates in the 21st century and
beyond - both date and datetime fields store at least 4-digit year number.

second, proposed folding of 2-digit year numbers is performed in current
implementation by time.strptime().

by the way, if you post a patch, please use unified diff format.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=746843&aid=3065292&group_id=140566

[dbfpy-devel] [ dbfpy-Bugs-3065292 ] y2k fix proposed

[SourceForge.net <no...@so...>]

Bugs item #3065292, was opened at 2010-09-13 17:32
Message generated for change (Tracker Item Submitted) made by jno-
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=746843&aid=3065292&group_id=140566

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: jno (jno-)
Assigned to: Nobody/Anonymous (nobody)
Summary: y2k fix proposed

Initial Comment:
Some applications still use DBF. This is a matter of fact.
But the DBF is not supposed to handle Y2K+ dates. But it does.
But the dbfpy cannot handle them. But it should.
So, I propose a [incomplete] fix to utils.getDate().

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=746843&aid=3065292&group_id=140566