Out and About

different from the .MDX/CDX (not to mention .NDX) format. The .DB’s use a primary key index that, if used, must be unique. Also available are secondary indexes (which first require the primary index) that not only allow for another view of the table like .MDXICDX’s, but are necessary for an Referential Integrity links. In any case, the primary index (key) is always in effect, meaning that it can’t have duplicate values no matter which secondary index you may be using to view your data. I should also mention that the primary key actually the order of table, which is something you almost never do with a .DBF. This can create an effect called flyaway, when an edited record suddenly disappears from view in a table as it’s automatically sorted to the proper position. (This was very disorienting to me the first time it happened, being used to dBASE III+ and .NDX indexes.) The final comment about indexes worth mentioning here is that you won’t have access to some of the .MDX/CDX indexing functions or operators with the .DB tables, nor will you be able to use descending indexes like you may be used to.

[Ed. Note: Randy’s article continues with a history of xBase, including the involvement of Borland and the technology that was acquired with the purchase of Arago. It is of enough significance to warrant a separate column. However, due to space limitations in this month’s newsletter, we will be printing it in its entirety in next month’s newsletter.)