Ed,

SNIP

I'm glad that you rasied this.

Reading the "Indexes" section of "Inside Microsoft SQL Server 7.0" it states that it too uses 'standard B-trees'.

This got me to wondering why VFP (and related) are always tagged as "ISAM" yet SQL Server is never treated as such. In fact I would say that most of what I read where this is mentioned typically refers to ISAM as older and less flexible and suggests that SQL Server is the better way because it is not ISAM (at least the implication that it is not ISAM is strong).

What am I missing here???

Regards,

Jim N


>Warning - grumpy programmer mode is on. BTREIVE is a specific (ISAM) file product; the B-Tree data structure is the underlying mechanism of most indexes found in use todsay 9there are LOTS of others, but b-trees and variants on them represent the bulk of index mechanisms in widespread use. I'd recommend Donald Knuth's Sorting and Searchning if you want to look at the mathematics of sorts and indexes at a theoretical level; most decent college textbooks on algorithms and data structures have at least a couple of chapters devoted to the topic, and will probably be a whole lot more approachable.)
>
>I think you're badly mistaken here. VFP uses balanced tree structures to implement its indexes, as do most other index mechanisms for other data products. The availability of record-oriented operations is a carryover of xBASE language rather than an artifact of the file system itself. The VFP engine can be made avaialble to another programming environment; the record-level metaphor can be implemented in another language, and VFP can handle the data for you through the ODBC driver or a VFP COM Server.
>
>In fact, the introduction of the DBC and the availability of things like parameterized views makes it possible to operate outside of the record-by-record approach of older xBASE programming, without affecting the performance of the underlying file manipulation. We're actively encouraged to move away from the older procedural model of application implementation.
>
>IOW, the underlying file system implementation and the language can vary independently. there are things inside of the VFP runtime that make VFP's native file manipulation very fast, in temrs of how memory resources are handled, the optimization technology, etc, but there's nothing preventing another language from encompassing the same engine s long as the engine's appetites and requirements were satisified.
>
SNIP