Changed parameter in Read from uint16 to int #2
Conversation
The uint16 can accomodate 65536 records, but dbf has no practical limits beyond maximum file size. int is guaranteed to be, at least, 32bit. Added some comment to methods. Changed FieldName to read up to the first "\x00" , some headers aren't padded with "\x00", so it could return a wrong field name. This happens with some Clipper compiled programs.
As far as I can tell, the existing |
|
Hi, strings.TrimRight removes all the trailing specified cutset runes. I didn't build a unit test (yet), but I do have a bunch of Clipper's generated dbf with this non standard format. I've met this problem before. Clipper (maybe, only some versions) doesn't pad the name field with 0x00. I suppose they didn't care, after all, if you're using a strcpy (from C) function, the padding is only a waste of time. The fields' names are something like: LibreOffice does import any of these slightly malformed dbf. See the sample attached. |
2 participants
The uint16 can accomodate 65536 records, but dbf has no practical limits beyond maximum file size.
int is guaranteed to be, at least, 32bit.
Added some comment to methods.
Changed FieldName to read up to the first "\x00" , some headers aren't padded with "\x00", so it could return a wrong field name.
This happens with some Clipper compiled programs.