>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???

Nothing - going back to the bad old big-iron IBM days, ISAM was "Indexed Sequential Access Method" (and QISAM was "Queued ISAM", basically a buffer strategy variant). Applications written to use ISAM weren't written from a database perspective; it was record-by record access, with explcit seeks in other files (tables) rather than a database-oriented (Set of Record orientation rather than record-by-record file navigation with explicit code to relate things.) If you remember the transition to VSAM with IMS, the ISAM memchanisms were incorporated ointo VSAM as 'flavors' of file organizations within a VSAM environment.

I think it's a lack of understanding that a B-Tree is a data structure that is common to both record and record set operations to implement indexes, and ISAM is a strategy of using an index and procesing an indexed file sequentially hitting here and causing confusion. In fact, we can see how SQL Server makes alternative index structures (like hash tables) available.

Loose terminology, on the part of people who should know better, is confusing the issue. The distinction between procedural code that spins through files record-by record rather than performing operations on a record set basis isn't a distinction between ISAM and B-Trees...