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

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

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

Well, here, because of my training, I may have overstated my case. As a programmer, I'm required to view things from a "worst case" scenario. The "worst case" here is that VFP will be forced to call all records across the line. Similarly, as a programmer, I'm required to prove all agorithims. Such being the case, tell me Jim, what methodology do you use to prove the following?

FUNCTION AddTwo

  LARAMETERS tnOne, tnTwo

  RETURN tnOne + tnTwo
ENDFUNC

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

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.

The thing here is, what the backend does, doesn't matter. What matters is what comes across the wire. But, for some reason, neither you nor Walter seem to think that it's of any significance.

>George, I know that SQLJim, my problem wit 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. 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.