After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 568454 - Gnumeric skips last row in dbase dbf file
Gnumeric skips last row in dbase dbf file
Status: RESOLVED FIXED
Product: Gnumeric
Classification: Applications
Component: import/export other
1.8.x
Other All
: Normal normal
: ---
Assigned To: Morten Welinder
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2009-01-20 17:09 UTC by Peter Hopfgartner
Modified: 2009-01-26 16:07 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
dbf file generated by pgsql2shp (9.16 KB, application/octet-stream)
2009-01-20 17:10 UTC, Peter Hopfgartner
Details
Screenshot of file opened in OpenOffice (76.64 KB, image/png)
2009-01-20 17:12 UTC, Peter Hopfgartner
Details
Screenshot of file opened in Gnumeric (64.53 KB, image/png)
2009-01-20 17:13 UTC, Peter Hopfgartner
Details

Description Peter Hopfgartner 2009-01-20 17:09:27 UTC
When reading the attached file, which was generated by pgsql2shp, an utility wich comes with PostGIS, Gnumeric 1.8.3, as packaged in Ubuntu 8.10, 64 bit, skips the last row. OpenOffice from the same Ubuntu version reads it.
Comment 1 Peter Hopfgartner 2009-01-20 17:10:54 UTC
Created attachment 126846 [details]
dbf file generated by pgsql2shp
Comment 2 Peter Hopfgartner 2009-01-20 17:12:42 UTC
Created attachment 126847 [details]
Screenshot of file opened in OpenOffice

Has 8 rows in OpenOffice (expected value)
Comment 3 Peter Hopfgartner 2009-01-20 17:13:29 UTC
Created attachment 126848 [details]
Screenshot of file opened in Gnumeric

Last row is missing
Comment 4 J.H.M. Dassen (Ray) 2009-01-23 10:52:10 UTC
This behaviour is reproducible with SVN trunk as well. Note also that
gnumeric is generating a warning for this file:
	** (gnumeric:32302): WARNING **: File has unknown or missing code page information (0)
as well as several CRITICALs regarding validation of dates:
	(gnumeric:32302): GLib-CRITICAL **: g_date_new_dmy: assertion `g_date_valid_dmy (day, m, y)' failed
	(gnumeric:32302): GLib-CRITICAL **: g_date_valid: assertion `d != NULL' failed
	(gnumeric:32302): GLib-CRITICAL **: g_date_get_julian: assertion `g_date_valid (d)' failed
	(gnumeric:32302): GLib-CRITICAL **: g_date_free: assertion `d != NULL' failed
etc.
which probably explain the missing date values in columns C, E, and P.
Comment 5 Morten Welinder 2009-01-23 16:20:30 UTC
Criticals and a crash related to formats fixed.
Comment 6 Morten Welinder 2009-01-23 16:43:50 UTC
The file is incorrect: it clearly states that there are 7 records (bytes 4-7):

hexdump -C ~/P200101.dbf | head -1
00000000  03 5f 07 1a 07 00 00 00  a1 05 6e 04 00 00 00 00  |._........n.....|

Please file a bug against the program that produced that file.
See http://www.clicketyclick.dk/databases/xbase/format/dbf.html#DBF_STRUCT
Comment 7 Morten Welinder 2009-01-23 16:45:26 UTC
And while we're at it, the file does not contain the required terminator:

hexdump -C ~/P200101.dbf | tail -2
000024a0  20 20 20                                          |   |
000024a3

(It should end in "1a".)
Comment 8 Peter Hopfgartner 2009-01-26 09:15:23 UTC
Reported to PostGIS

http://code.google.com/p/postgis/issues/detail?id=105
Comment 9 Morten Welinder 2009-01-26 16:05:57 UTC
Correction: comment 6 is confused.  Yes, the file says 7.  That's because
there are 7.

Comment 7 is valid, though, and is the reason we reject the final record.

I'll fix that, but PostGIS should still be fixed to produce files that are
up to spec.
Comment 10 Morten Welinder 2009-01-26 16:07:45 UTC
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.