home *** CD-ROM | disk | FTP | other *** search
/ DP Tool Club 31 / CDASC_31_1996_juillet_aout.iso / vrac / del2faq.zip / TI2821.ZIP / TI2821.ASC
Text File  |  1996-02-28  |  19KB  |  427 lines
  1.    NUMBER  :  2821
  2.   PRODUCT  :  Delphi
  3.   VERSION  :  All
  4.        OS  :  Windows/Win32
  5.      DATE  :  February 28, 1996                       
  6.  
  7.     TITLE  :  dBASE .DBF File Structure
  8.  
  9. Sometimes it is necessary to delve into a dBASE table outside the control
  10. of the Borland Database Engine (BDE). For instance, if the .DBT file (that
  11. contains memo data) for a given table is irretrievably lost, the file will
  12. not be usable because the byte in the file header indicates that there
  13. should be a corresponding memo file. This necessitates toggling this byte
  14. to indicate no such accompanying memo file. Or, you may just want to write
  15. your own data access routine.
  16.  
  17. Below are the file structures for dBASE table files. Represented are the
  18. file structures as used for various versions of dBASE: dBASE III PLUS 1.1,
  19. dBASE IV 2.0, dBASE 5.0 for DOS, and dBASE 5.0 for Windows.
  20.  
  21. **************************************************************************
  22. The data file header structure for dBASE III PLUS table file.
  23. **************************************************************************
  24.  
  25. The table file header:
  26. ======================
  27.  
  28. Byte  Contents    Description
  29. ----- --------    --------------------------------------------------------
  30. 0     1 byte      Valid dBASE III PLUS table file (03h without a memo 
  31.                   (.DBT file; 83h with a memo).
  32.  
  33. 1-3   3 bytes     Date of last update; in YYMMDD format.
  34. 4-7   32-bit      Number of records in the table.
  35.       number
  36. 8-9   16-bit      Number of bytes in the header.
  37.       number
  38. 10-11 16-bit      Number of bytes in the record.
  39.       number
  40. 12-14 3 bytes     Reserved bytes.
  41. 15-27 13 bytes    Reserved for dBASE III PLUS on a LAN.
  42. 28-31 4 bytes     Reserved bytes.
  43. 32-n  32 bytes    Field descriptor array (the structure of this array is
  44.       each        shown below)
  45. n+1   1 byte      0Dh stored as the field terminator.
  46.  
  47. n above is the last byte in the field descriptor array. The size of the
  48. array depends on the number of fields in the table file.
  49.  
  50. Table Field Descriptor Bytes
  51. ============================
  52.  
  53. Byte  Contents    Description
  54. ----- --------    --------------------------------------------------------
  55. 0-10  11 bytes    Field name in ASCII (zero-filled).
  56. 11    1 byte      Field type in ASCII (C, D, L, M, or N).
  57. 12-15 4 bytes     Field data address (address is set in memory; not useful
  58.                   on disk).
  59. 16    1 byte      Field length in binary.
  60. 17    1 byte      Field decimal count in binary.
  61. 18-19 2 bytes     Reserved for dBASE III PLUS on a LAN.
  62. 20    1 byte      Work area ID.
  63. 21-22 2 bytes     Reserved for dBASE III PLUS on a LAN.
  64. 23    1 byte      SET FIELDS flag.
  65. 24-31 1 byte      Reserved bytes.
  66.  
  67. Table Records
  68. =============
  69.  
  70. The records follow the header in the table file. Data records are preceded
  71. by one byte, that is, a space (20h) if the record is not deleted, an
  72. asterisk (2Ah) if the record is deleted. Fields are packed into records
  73. without field separators orrecord terminators. The end of the file is
  74. marked by a single byte, with the end-of-file marker, an OEM code page
  75. character value of 26 (1Ah). You can input OEM code page data as indicated
  76. below.
  77.  
  78. Allowable Input for dBASE Data Types
  79. ====================================
  80.  
  81. Data Type      Data Input
  82. -------------- -----------------------------------------------------------
  83. C (Character)  All OEM code page characters.
  84. D (Date)       Numbers and a character to separate month, day, and year
  85.                (stored internally as 8 digits in YYYYMMDD format).
  86. N (Numeric)    - . 0 1 2 3 4 5 6 7 8 9
  87. L (Logical)    ? Y y N n T t F f (? when not initialized).
  88. M (Memo)       All OEM code page characters (stored internally as 10 
  89.                digits representing a .DBT block number).
  90.  
  91. Binary, Memo, and OLE Fields And .DBT Files
  92. ===========================================
  93.  
  94. Memo fields store data in .DBT files consisting of blocks numbered 
  95. sequentially (0, 1, 2, and so on). The size of these blocks are internally
  96. set to 512 bytes. The first block in the .DBT file, block 0, is the .DBT
  97. file header.
  98.  
  99. Memo field of each record in the .DBF file contains the number of the
  100. block (in OEM code page values) where the field's data actually begins. If
  101. a field contains no data, the .DBF file contains blanks (20h) rather than
  102. a number.
  103.  
  104. When data is changed in a field, the block numbers may also change and the
  105. number in the .DBF may be changed to reflect the new location.
  106.  
  107. This information is from the Using dBASE III PLUS manual, Appendix C.
  108.  
  109. **************************************************************************
  110. The data file header structure for dBASE IV 2.0 table file.
  111. **************************************************************************
  112.  
  113. File Structure:
  114. ===============
  115.  
  116. Byte     Contents       Meaning
  117. -------  ----------     -------------------------------------------------
  118. 0        1byte          Valid dBASE IV file; bits 0-2 indicate version
  119.                         number, bit 3 the presence of a dBASE IV memo
  120.                         file, bits 4-6 the presence of an SQL table, bit
  121.                         7 the presence of any memo file (either dBASE III
  122.                         PLUS or dBASE IV).
  123. 1-3      3 bytes        Date of last update; formattted as YYMMDD.
  124. 4-7      32-bit number  Number of records in the file.
  125. 8-9      16-bit number  Number of bytes in the header.
  126. 10-11    16-bit number  Number of bytes in the record.
  127. 12-13    2 bytes        Reserved; fill with 0.
  128. 14       1 byte         Flag indicating incomplete transaction.
  129. 15       1 byte         Encryption flag.
  130. 16-27    12 bytes       Reserved for dBASE IV in a multi-user environment.
  131. 28       1 bytes        Production MDX file flag; 01H if there is an MDX,
  132.                         00H if not.
  133. 29       1 byte         Language driver ID.
  134. 30-31    2 bytes        Reserved; fill with 0.
  135. 32-n*    32 bytes each  Field descriptor array (see below).
  136. n + 1    1 byte         0DH as the field terminator.
  137.  
  138. * n is the last byte in the field descriptor array. The size of the array
  139. depends on the number of fields in the database file.
  140.  
  141. The field descriptor array:
  142. ===========================
  143.  
  144. Byte     Contents       Meaning
  145. -------  ------------   --------------------------------------------------
  146. 0-10     11 bytes       Field name in ASCII (zero-filled).
  147. 11       1 byte         Field type in ASCII (C, D, F, L, M, or N).
  148. 12-15    4 bytes        Reserved.
  149. 16       1 byte         Field length in binary.
  150. 17       1 byte         Field decimal count in binary.
  151. 18-19    2 bytes        Reserved.
  152. 20       1 byte         Work area ID.
  153. 21-30    10 bytes       Reserved.
  154. 31       1 byte         Production MDX field flag; 01H if field has an 
  155.                         index tag in the production MDX file, 00H if not.
  156.  
  157. Database records:
  158. =================
  159.  
  160. The records follow the header in the database file. Data records are
  161. preceded by one byte; that is, a space (20H) if the record is not deleted,
  162. an asterisk (2AH) if the record is deleted. Fields are packed into
  163. records without field separators or record terminators. The end of the 
  164. file is marked by a single byte, with the end-of-file marker an ASCII 26
  165. (1AH) character.
  166.  
  167. Allowable Input for dBASE Data Types:
  168. ====================================
  169.  
  170. Data  Type           Data Input
  171. ----  ----------     -----------------------------------------------------
  172. C     (Character)    All OEM code page characters.
  173. D     (Date)         Numbers and a character to separate month, day, and
  174.                      year (stored internally as 8 digits in YYYYMMDD
  175.                      format).
  176. F     (Floating      - . 0 1 2 3 4 5 6 7 8 9
  177.       point binary
  178.       numeric)
  179. N     (Binary        - . 0 1 2 3 4 5 6 7 8 9
  180.       coded decimal
  181.       numeric)   
  182. L     (Logical)      ? Y y N n T t F f (? when not initialized).
  183. M     (Memo)         All OEM code page characters (stored internally as 10
  184.                      digits representing a .DBT block number).
  185.  
  186. Memo Fields And .DBT Files
  187. ===========================================
  188.  
  189. Memo fields store data in .DBT files consisting of blocks numbered 
  190. sequentially (0, 1, 2, and so on). SET BLOCKSIZE determines the size of
  191. each block. The first block in the .DBT file, block 0, is the .DBT file
  192. header.
  193.  
  194. Each memo field of each record in the .DBF file contains the number of the
  195. block (in OEM code page values) where the field's data actually begins. If
  196. a field contains no data, the .DBF file contains blanks (20h) rather than
  197. a number.
  198.  
  199. When data is changed in a field, the block numbers may also change and the
  200. number in the .DBF may be changed to reflect the new location.
  201.  
  202. This information is from the dBASE IV Language Reference manual, Appendix
  203. D.
  204.  
  205. **************************************************************************
  206. The data file header structure for dBASE 5.0 for DOS table file.
  207. **************************************************************************
  208.  
  209. The table file header:
  210. ======================
  211.  
  212. Byte  Contents    Description
  213. ----- --------    --------------------------------------------------------
  214. 0     1 byte      Valid dBASE for Windows table file; bits 0-2 indicate
  215.                   version number; bit 3 indicates presence of a dBASE IV
  216.                   or dBASE for Windows memo file; bits 4-6 indicate the
  217.                   presence of a dBASE IV SQL table; bit 7 indicates the
  218.                   presence of any .DBT memo file (either a dBASE III PLUS
  219.                   type or a dBASE IV or dBASE for Windows memo file).
  220. 1-3   3 bytes     Date of last update; in YYMMDD format.
  221. 4-7   32-bit      Number of records in the table.
  222.       number
  223. 8-9   16-bit      Number of bytes in the header.
  224.       number
  225. 10-11 16-bit      Number of bytes in the record.
  226.       number
  227. 12-13 2 bytes     Reserved; filled with zeros.
  228. 14    1 byte      Flag indicating incomplete dBASE transaction.
  229. 15    1 byte      Encryption flag.
  230. 16-27 12 bytes    Reserved for multi-user processing.
  231. 28    1 byte      Production MDX flag; 01h stored in this byte if a prod-
  232.                   uction .MDX file exists for this table; 00h if no .MDX
  233.                   file exists.
  234. 29    1 byte      Language driver ID.
  235. 30-31 2 bytes     Reserved; filled with zeros.
  236. 32-n  32 bytes    Field descriptor array (the structure of this array is
  237.       each        shown below)
  238. n+1   1 byte      0Dh stored as the field terminator.
  239.  
  240. n above is the last byte in the field descriptor array. The size of the
  241. array depends on the number of fields in the table file.
  242.  
  243. Table Field Descriptor Bytes
  244. ============================
  245.  
  246. Byte  Contents    Description
  247. ----- --------    --------------------------------------------------------
  248. 0-10  11 bytes    Field name in ASCII (zero-filled).
  249. 11    1 byte      Field type in ASCII (B, C, D, F, G, L, M, or N).
  250. 12-15 4 bytes     Reserved.
  251. 16    1 byte      Field length in binary.
  252. 17    1 byte      Field decimal count in binary.
  253. 18-19 2 bytes     Reserved.
  254. 20    1 byte      Work area ID.
  255. 21-30 10 bytes    Reserved.
  256. 31    1 byte      Production .MDX field flag; 01h if field has an index
  257.                   tag in the production .MDX file; 00h if the field is not
  258.                   indexed.   
  259.  
  260. Table Records
  261. =============
  262.  
  263. The records follow the header in the table file. Data records are preceded
  264. by one byte, that is, a space (20h) if the record is not deleted, an
  265. asterisk (2Ah) if the record is deleted. Fields are packed into records
  266. without field separators orrecord terminators. The end of the file is
  267. marked by a single byte, with the end-of-file marker, an OEM code page
  268. character value of 26 (1Ah). You can input OEM code page data as indicated
  269. below.
  270.  
  271. Allowable Input for dBASE Data Types
  272. ====================================
  273.  
  274. Data Type      Data Input
  275. -------------- -----------------------------------------------------------
  276. C (Character)  All OEM code page characters.
  277. D (Date)       Numbers and a character to separate month, day, and year
  278.                (stored internally as 8 digits in YYYYMMDD format).
  279. F (Floating    - . 0 1 2 3 4 5 6 7 8 9
  280.   point binary
  281.   numeric)
  282. N (Numeric)    - . 0 1 2 3 4 5 6 7 8 9
  283. L (Logical)    ? Y y N n T t F f (? when not initialized).
  284. M (Memo)       All OEM code page characters (stored internally as 10
  285.                digits representing a .DBT block number).
  286.  
  287. Memo Fields And .DBT Files
  288. ===========================================
  289.  
  290. Memo fields store data in .DBT files consisting of blocks numbered 
  291. sequentially (0, 1, 2, and so on). SET BLOCKSIZE determines the size of
  292. each block. The first block in the .DBT file, block 0, is the .DBT file
  293. header.
  294.  
  295. Each memo field of each record in the .DBF file contains the number of the
  296. block (in OEM code page values) where the field's data actually begins. If
  297. a field contains no data, the .DBF file contains blanks (20h) rather than
  298. a number.
  299.  
  300. When data is changed in a field, the block numbers may also change and the
  301. number in the .DBF may be changed to reflect the new location.
  302.  
  303. Unlike dBASE III PLUS, if you delete text in a memo field, dBASE 5.0 for
  304. DOS may reuse the space from the deleted text when you input new text.
  305. dBASE III PLUS always appends new text to the end of the .DBT file. In
  306. dBASE III PLUS, the .DBT file size grows whenever new text is added, even
  307. if other text in the file is deleted.
  308.  
  309. This information is from the dBASE for DOS Language Reference manual, 
  310. Appendix C.
  311.  
  312. **************************************************************************
  313. The data file header structure for dBASE 5.0 for Windows table file.
  314. **************************************************************************
  315.  
  316. The table file header:
  317. ======================
  318.  
  319. Byte  Contents    Description
  320. ----- --------    --------------------------------------------------------
  321. 0     1 byte      Valid dBASE for Windows table file; bits 0-2 indicate
  322.                   version number; bit 3 indicates presence of a dBASE IV
  323.                   or dBASE for Windows memo file; bits 4-6 indicate the
  324.                   presence of a dBASE IV SQL table; bit 7 indicates the
  325.                   presence of any .DBT memo file (either a dBASE III PLUS
  326.                   type or a dBASE IV or dBASE for Windows memo file).
  327. 1-3   3 bytes     Date of last update; in YYMMDD format.
  328. 4-7   32-bit      Number of records in the table.
  329.       number
  330. 8-9   16-bit      Number of bytes in the header.
  331.       number
  332. 10-11 16-bit      Number of bytes in the record.
  333.       number
  334. 12-13 2 bytes     Reserved; filled with zeros.
  335. 14    1 byte      Flag indicating incomplete dBASE IV transaction.
  336. 15    1 byte      dBASE IV encryption flag.
  337. 16-27 12 bytes    Reserved for multi-user processing.
  338. 28    1 byte      Production MDX flag; 01h stored in this byte if a prod-
  339.                   uction .MDX file exists for this table; 00h if no .MDX
  340.                   file exists.
  341. 29    1 byte      Language driver ID.
  342. 30-31 2 bytes     Reserved; filled with zeros.
  343. 32-n  32 bytes    Field descriptor array (the structure of this array is
  344.       each        shown below)
  345. n+1   1 byte      0Dh stored as the field terminator.
  346.  
  347. n above is the last byte in the field descriptor array. The size of the
  348. array depends on the number of fields in the table file.
  349.  
  350. Table Field Descriptor Bytes
  351. ============================
  352.  
  353. Byte  Contents    Description
  354. ----- --------    --------------------------------------------------------
  355. 0-10  11 bytes    Field name in ASCII (zero-filled).
  356. 11    1 byte      Field type in ASCII (B, C, D, F, G, L, M, or N).
  357. 12-15 4 bytes     Reserved.
  358. 16    1 byte      Field length in binary.
  359. 17    1 byte      Field decimal count in binary.
  360. 18-19 2 bytes     Reserved.
  361. 20    1 byte      Work area ID.
  362. 21-30 10 bytes    Reserved.
  363. 31    1 byte      Production .MDX field flag; 01h if field has an index
  364.                   tag in the production .MDX file; 00h if the field is not
  365.                   indexed.   
  366.  
  367. Table Records
  368. =============
  369.  
  370. The records follow the header in the table file. Data records are preceded
  371. by one byte, that is, a space (20h) if the record is not deleted, an
  372. asterisk (2Ah) if the record is deleted. Fields are packed into records
  373. without field separators orrecord terminators. The end of the file is
  374. marked by a single byte, with the end-of-file marker, an OEM code page
  375. character value of 26 (1Ah). You can input OEM code page data as indicated
  376. below.
  377.  
  378. Allowable Input for dBASE Data Types
  379. ====================================
  380.  
  381. Data Type      Data Input
  382. -------------- -----------------------------------------------------------
  383. B (Binary)     All OEM code page characters (stored internally as 10
  384.                digits representing a .DBT block number).
  385. C (Character)  All OEM code page characters.
  386. D (Date)       Numbers and a character to separate month, day, and year
  387.                (stored internally as 8 digits in YYYYMMDD format).
  388. G (General     All OEM code page characters (stored internally as 10
  389.                digits or OLE) representing a .DBT block number).
  390. N (Numeric)    - . 0 1 2 3 4 5 6 7 8 9
  391. L (Logical)    ? Y y N n T t F f (? when not initialized).
  392. M (Memo)       All OEM code page characters (stored internally as 10
  393.                digits representing a .DBT block number).
  394.  
  395. Binary, Memo, and OLE Fields And .DBT Files
  396. ===========================================
  397.  
  398. Binary, memo, and OLE fields store data in .DBT files consisting of blocks
  399. numbered sequentially (0, 1, 2, and so on). SET BLOCKSIZE determines the
  400. size of each block. The first block in the .DBT file, block 0, is the .DBT
  401. file header.
  402.  
  403. Each binary, memo, or OLE field of each record in the .DBF file contains
  404. the number of the block (in OEM code page values) where the field's data
  405. actually begins. If a field contains no data, the .DBF file contains
  406. blanks (20h) rather than a number.
  407.  
  408. When data is changed in a field, the block numbers may also change and the
  409. number in the .DBF may be changed to reflect the new location.
  410.  
  411. Unlike dBASE III PLUS, if you delete text in a memo field (or binary and
  412. OLE fields), dBASE for Windows (unlike dBASE IV) may reuse the space from
  413. the deleted text when you input new text. dBASE III PLUS always appends
  414. new text to the end of the .DBT file. In dBASE III PLUS, the .DBT file
  415. size grows whenever new text is added, even if other text in the file is
  416. deleted.
  417.  
  418. This information is from the dBASE for Windows Language Reference manual, 
  419. Appendix C.
  420.  
  421.  
  422.  
  423. DISCLAIMER: You have the right to use this technical information
  424. subject to the terms of the No-Nonsense License Statement that
  425. you received with the Borland product to which this information
  426. pertains.
  427.