You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Reported by d321321, Feb 3, 2013
Where a DBF file is not terminated with the expected 0x1A end-of-file marker, the DBFReader.NextRecord method throws an error when EOF is encountered, rather than returning null as expected.
Using information contained in the header area (such as the offset to the first data record, the number of records in the file and the size of each record, the code could easily tell when the end-of-file is reached.
What steps will reproduce the problem?
With a valid .DBF file, open with DBFReader and call NextRecord until null is returned. The last byte in the file is expected to be 0x1F.
Using the Free DBF Viewer (www.dbfviewer.org), add a new record into the file. The new record is added to the end of the file, and the final byte is 'moved'. In some cases I found this final byte to be 0x0F, but I've seen other values too.
Open the modified .DBF file and call NextRecord until null is returned. In this case, a DBFException is thrown saying 'Failed to parse Number'.
What is the expected output? What do you see instead?
Upon reaching the end-of-file, NextRecord should return null, instead it throws a DBFException as it tries to process a non-existent record.
What version of the product are you using? On what operating system?
Version dotnetdbf 3.1.0, on Windows XP
Please provide any additional information below.
I have used http://www.dbf2002.com/dbf-file-format.html as a guide to the dbf specification (although it is silent on what character, if any, should appear after the data records).
Line 225 of DBFReader.cs suggests that it expects an EOF marker.
if (t_byte == DBFFieldType.EndOfData)
I suggest that when the _header object is constructed (in DBFHeader.Read), the offset of the end of the data records be calculated, to be stored in a new property in DBFHeader:
_expectedEndOfFile = (long)HeaderLength +
NumberOfRecords * RecordSize;
Then, in NextRecord, just before the EOF is checked (say at line 223), the position in the stream is also checked, for example:
if (_dataInputStream.BaseStream.Position >=
_header.ExpectedEndOfFile) return null;
That way, NextRecord will exit when the defined number of records have been retrieved, regardless of what terminating character is used.
The text was updated successfully, but these errors were encountered:
Reported by d321321, Feb 3, 2013
Where a DBF file is not terminated with the expected 0x1A end-of-file marker, the DBFReader.NextRecord method throws an error when EOF is encountered, rather than returning null as expected.
Using information contained in the header area (such as the offset to the first data record, the number of records in the file and the size of each record, the code could easily tell when the end-of-file is reached.
What steps will reproduce the problem?
What is the expected output? What do you see instead?
Upon reaching the end-of-file, NextRecord should return null, instead it throws a DBFException as it tries to process a non-existent record.
What version of the product are you using? On what operating system?
Version dotnetdbf 3.1.0, on Windows XP
Please provide any additional information below.
I have used http://www.dbf2002.com/dbf-file-format.html as a guide to the dbf specification (although it is silent on what character, if any, should appear after the data records).
Line 225 of DBFReader.cs suggests that it expects an EOF marker.
if (t_byte == DBFFieldType.EndOfData)
I suggest that when the _header object is constructed (in DBFHeader.Read), the offset of the end of the data records be calculated, to be stored in a new property in DBFHeader:
_expectedEndOfFile = (long)HeaderLength +
NumberOfRecords * RecordSize;
Then, in NextRecord, just before the EOF is checked (say at line 223), the position in the stream is also checked, for example:
if (_dataInputStream.BaseStream.Position >=
_header.ExpectedEndOfFile) return null;
That way, NextRecord will exit when the defined number of records have been retrieved, regardless of what terminating character is used.
The text was updated successfully, but these errors were encountered: