GNOME Bugzilla – Bug 568454
Gnumeric skips last row in dbase dbf file
Last modified: 2009-01-26 16:07:45 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.
Created attachment 126846 [details] dbf file generated by pgsql2shp
Created attachment 126847 [details] Screenshot of file opened in OpenOffice Has 8 rows in OpenOffice (expected value)
Created attachment 126848 [details] Screenshot of file opened in Gnumeric Last row is missing
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.
Criticals and a crash related to formats fixed.
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
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".)
Reported to PostGIS http://code.google.com/p/postgis/issues/detail?id=105
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.
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.