SNIP
>
>Appearances are deceiving. Chapter Six of "Inside SQL Server 7.0" delinates the differences pretty well, especially beginning at page 229.

Right, they have created a number of additional 'structural entities' within the data storage, for various purposes. Our cheaper VFP has, that I know of, only the bits to indicate NULL as extra baggage (UPDATE: I guess the .DBC is another), while SQL Server has lots.
SQL Server makes use of B-tree indexes. Again, theirs may differ in add-ons from VFP's, but at their roots they are the same. I suppose that VFP's compact index format might illustrate a difference on its side.
Clustered indexes, a misnomer if I ever saw one, don't exist in VFP of course, and they too require additional structural factors to implement.

It still looks to me like both are technically "ISAM" (or at least more ISAM than any other term), SQL Server having much much more in the way added specialized structural entities to deliver all of the added (and most useful) functionality.

Trying an analogy: We ALL understand that a Beetle and a Rolls Royce are fundamentally the same thing but one offers amenities, for a price, that the other doesn't. If someone (other than a marketer) was discussing the virtues of a Rolls Royce they would NOT say '...so why would you want to buy a car...' because there would be no evident differentiation between the Beetle and the Rolls Royce. Now, because we (the general developer community, not your software internals gurus) don't know enough about ISAM or SQL Server or lots of other things, a person **CAN** get away with a statement like '...so why would you use ISAM for...', suggesting that there IS a difference between ISAM and the product they want to promote.
My contention is that there are far more similarities than there are differences and they are relying on our ignorance to generate the perception of differences that do not exist in substance. They couldn't get away with the same thing for cars, because we all know enough to call them on it. With the term "ISAM" they can get away with it, but we shouldn't let them.

Cheers

>
>I know that you weren't accusing me of spreading FUD. ISAM has its short-comings as does SQL Server. Let me give you a real life example.
>
>I have to migrate to SQL Server from native tables. There are series of 14 or 15 systems referred to as "Efficiency Systems" (there are numerous processes and each has its own system). A couple of these have different reports that break down the same information in numerous different ways (one system has 27 different breakdowns).
>
>In VFP, using native tables I can create a single query, passing parameters that can build the cursors used in the reports.
>
>In a meeting earlier this week, in talking about about the migration, I mentioned the number of different reports and said, "I don't really thing that you want to have over 10 different stored procedures to return the result sets." I was looking straight at the DBA, and saw the look of horror on her face when she realized the implications of this.
>
>The problem here is that SQL Server will not allow you to include fields that aren't in the group by clause when aggregate functions are used. In VFP, you can do this.
>
>The best solution (especially since the code already exists) is to pull over the range of data desired, then execute a query in VFP to produce the result sets. In this scenario, there's one stored procedure on SQL Server and one in VFP to maintain, rather than 10, 15 or 20 SPs in SQL Server.