>Thanks Ed,
>
>So could I say that writing that (disparagingly, in my opinion) says that VFP 'is ISAM' as an excuse for whatever they are pushing (like SQL Server, or using it as to why we cannot have a OLEDB for VFP tables) are misinformed?
>

Yep. Anything that maintains an index, operates on the file directly and allows record-by-record traversal of a file 'is' an ISAM file system. You can write procedural record-by-record code in any of a number of languages. VFP does not force you to operate procedurally, even against its native file system, and so offers the option of traditional, xBASE-style "ISAMmy" programming or using the recordset approach to data manipulation. Clearly, since we can access data from backends that don't have a native record-oriented approach to accessing the data, we aren't locked into traditional xBASE programming style, and I'd expect that we'd have better integration of OLEDB into VFP at some point in time, where perhaps VFP cursors can take on the behaviors of an OLEDB recordset. This is speculation, though, nothing more.

SQL Server's advantages are not that it doesn't use indexed sequential access when that's the proper approach to take. Other issues such as scalability, size, richness of data structures, security as well as reduced bandwidth requirements to satisfy queries that result in small recordsets are far more compelling, and the ability to offer these services to another product, including VFP, is their strength. VFP's engine does process things locally rather than at the point that the data resides in many cases, resulting in a higher bandwidth requirement, but it can use a backend and forego its native file handling when that offers benefits.

>And could I also say that, because VFP has a fairly rich SQL capability, it is MORE than a 'procedural' language and so deserves more consideration than it generally seems to get?
>

Yep - you can generally skin a cat in more ways with VFP than with most other languages, at least from a data handling perspective.

>Cheers,
>
>Jim N
>
>>>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...