home *** CD-ROM | disk | FTP | other *** search
- Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
- Path: sparky!uunet!wupost!ukma!psuvax1!psuvm!auvm!INDYVAX.BITNET!DSMITH
- X-Envelope-to: DBASE-L@NMSUVM1.BITNET
- X-VMS-To: IN%"DBASE-L@NMSUVM1.BITNET"
- X-VMS-Cc: DSMITH
- MIME-version: 1.0
- Content-type: TEXT/PLAIN; CHARSET=US-ASCII
- Content-transfer-encoding: 7BIT
- Message-ID: <01GOJ9CDW5J6002H1X@INDYVAX.IUPUI.EDU>
- Newsgroups: bit.listserv.dbase-l
- Date: Tue, 8 Sep 1992 08:13:36 -0500
- Sender: "Discussion on the use of the dBase language and related
- dialects" <DBASE-L@NMSUVM1.BITNET>
- From: DON SMITH <DSMITH@INDYVAX.BITNET>
- Subject: Re: dbase questions + ASCII --> dbase
- Lines: 20
-
- Maarten -
- The number of records in a .DBF file is indeed stored in the header, in
- bytes 4-7 (start counting with 0). But as far as interpreting those bytes,
- they are stored in hexadecimal in that PC-peculiar "back-words" format, or
- whatever you want to call it. The proper order for us humans is byte 7 - byte
- 6 - byte 5 - byte 4.
-
- For example, a .DBF with 1044 records will have
- 14 04 00 00 stored in those bytes
- Rearrange to 00 00 04 14 and convert to decimal...
- (4 x 256) + (1 x 16) + (4 x 1) = 1044
-
- As far as efficiency of storage goes, yes, it does waste space to store a
- 10-character last name in 20 spaces, but it undoubtedly is simpler in the long
- run. Otherwise, imagine the convolutions in trying to edit the improperly
- spelled "Marten" to "Maarten" if the most storage-efficient methods were used.
- So there are tradeoffs either way. Simplicity has its virtues, especially if
- you're trying to put a damaged file back together!
-
- Don Smith
-