SNIP
>
>I'm copying Jim here so he can "get it".
>
>You guys don't seem to get it. Let me summarize what I've been saying for the sake of beverity and clarity.
>
>In the instance of VFP databases and tables residing on the server, anytime a table is opened, it requires that, at least a portion of the data at a minimum, be sent across the wire. Further, in the instance of a compact/compound index exsisting, it requires that information regarding that also be sent across the wire.
>
>Assuming an SQL statement, at best, VFP has to load the appropriate index, which is one trip, then request the specific records matching the WHEN clause across, which is another.
>
>In the instance that no index tag matching the criteria exists, VFP may be forced to build such. This is from the documentation. If the previous statement is true or false is irrelevant. In either case, VFP is forced to retrieve every record from the server to see if it matches the criteria.
>
>If records are updated they must be sent back across the wire, one by one. If the update requires a change to the index, that too must be sent.
>
>With a set-base backend server, such as SQL Server, no such trips apply. You request data matching the criteria. The server sends back the matches. When the client updates the records affected are sent back across the wire once. SQL Server takes care of the rest.
>
>This applies not only to single tables, but those created via a JOIN.
>
>To JN,
>
>I'd suggest that you start reading "Inside SQL Server 7.0" at about page 610. The section is named "Cursors And ISAM". It's obvious that you haven't gotten that far, otherwise you wouldn't be writing what you've written.
>
>If anything in the above is out of line with what I've written, please post page and paragraph numbers to illustrate. If the above isn't out of line, please let Walter know.


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

You replied in Thread #605216 Message #612664 as follows:
"One significant difference between an SQL Server table and a VFP table is that the latter is file based. This is part of the definition of what an IASM table is. IOW, you cannot open an ISAM table without retrieving all the records. You can with SQL Server because it requires you to describe what records you want. A VFP query requires that the underlying table (all of it) be opened and, therefore, cannot be considered to be the same.".

And this is what began the whole dialogue that followed.

Now your statements above (current message) are at variance with yours that started our dialogue.

As regards my reading of the book, I did read the whole thing when I went through it. I read the stuff on THEIR "cursors" and I read their frequent references to "ISAM" and the negative characterizations that always accompanied the reference. But I never came across what SQL Server's 'access method' is called. It just doesn't seem to have a name. Did you see it named in the book?
Based on what I read in that book I concluded that it, too, was "ISAM", despite all of the attempts in that book to characterize "ISAM" as something 'different'. Internally in SQL Server they appear to me to be using the identical techniques to what are used in other "ISAM" (as they themselves name them) applications, and they never give a name to the technique/access-method they do use inside SQL Server.

George, I know that SQl Server is radically more powerful and has SQL capabilities that we can only dream of in VFP. I've seen many people write here that they found transitioning to SQL Server real easy because the SQL syntax was virtually identical. That's good, but they are going to miss out on a whole lot of really useful features if they continue with only the very limited capabilities of VFP SQL in their SQL Server systems.

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