George,

SNIP
>>
>>In a reply to Jesse Banga, Thread #605216 Message #612571, I wrote:
>>"I rather think it's a problem because THESE (VFP) "ISAM" databases have not had the intelligence applied that other, more expensive (and that's what you pay extra for, I suppose) database systems that also are essentially "ISAM", have.
>>
>>Reading "Inside SQL Server 7.0" a while back made it quite clear to me that SQL Server tables are "ISAM" too as they are STORED and as they are RETRIEVED. The difference seemed to me largely that they had invented a few more gizmos that add significant value to the product as a whole.
>
>I fail to see how anyone can claim that an SQL Server table is an ISAM. The internal sturctures are completely different. SQL Server's table are not contiguous file blocks. Each page contains information regarding the data there, plus pointers to the previous and next pages, and offesets in the individual records. By contrast, VFP's records are store in a contiguous block.

First let me ask again: did you come across, in your reading of the book, the name of the access mechanism employed internally in SQL Server? I didn't, but could easily have missed it. My personal guess is that if it was really THAt different they would be proud of it and give it a name.
VFP's records are only "logically" stored in a contiguous block. Any given table can be fragmented to hell.
My take is that SQL Server invested the extra development to have 'controlled fragmentation' (my term) so that they could have more strict control over performance overall.
It is probable, for instance, that FP's creators did something similar with .CDX files - internal structures with offsets that THEIR code knows how to interpret.
>
>>I just don't see calling VFP's tables "ISAM" without also calling SQL Server tables "ISAM". Your doing so suggests a distinction that, for all intents and purposes, does not exist. What would you call SQL Server's storage/retrieval method?".
>
>The difference, and this is what I don't think you or Walter get, is that the backend mechhnics don't matter. What matters it how the result set is delivered to and from across the line.

Walter will address his issue(s).
As for me, this is the crux of the matter right here! My statement never mentioned frontend/backend or across the wire.
My statement simply said that SQL Server's STORAGE and RETRIEVAL mechanism (implying it's INTERNAL workings, but maybe that was not clear) sure appeared to me to be very ISAM-like, to the point that I would personally call it "ISAM", especially in the absence of any other name by its inventors.

And the reason I mentioned it was because I constantly read references to "ISAM", especially in SQL Server literature, that are derogatory in the sense that it is 'old' and 'too traditional for modern systems' etc.
I was making the point to Jess that blaming "ISAM" for problems may not be all that accurate because SQl Server looks suspiciously like "ISAM" too (under the covers).
Kinda like someone mocking your choice of a product (say toothpaste), only to find out that they too use the same product.

>
SNIP
>
>Well at least here we have something solid to deal with. What we have here is you disagreeing with the people who designed the product and, in the process, failing to take into consideration the significant differences between the file structures and coming to the conclusion that they are fundamentality the same.

Hopefully my comments above clarify this. I'm not disagreeing with the people who designed the product at all. I'm not disagreeing with the general content of the book either. I am simply taking issue with the book's (and other publicity I see often) propensity to name "ISAM" as a poor choice when SQL Server looks like ISAM to me (internally). I'd really like to know what the name is for SQL Server's internal access method.
>
SNIP
>>
>>I think that it is commendable that SQL Server has been able to deliver what it delivers. I simply take issue, and significantly, with the book's implications that "ISAM" is a 'yesterdays choice' for serious development, especially when they never name what has replaced it in SQL Server's domain. I contend that SQL Server itself is built with "ISAM" internally and that, using "ISAM" they have delivered a different way to search/update data at a user level.
>>
>
>Jim. my problem with this whole issue is very simple. I keep offerring up documentation, outside resources, and even registry entries to prove my point. Have you or Walter offered up one such thing to disprove what I've said. The answer is an empathic, "No!" I'll let the readers of this post decide who know what here.

Yep, you are offering lots up. Just not about *my* issue.