Walter,
>
>I get the feeling we are talking about apples and oranges.

We certainly are...

>>>I'm sure you don't mean this. Of course I could OPEN a VFP table without retrieving all its records, else it would be impossible to work with 2 gig files on a network.
>>
>>I certainly do mean it. Issue GOTO BOTTOM on an ISAM (VFP table) an you go to the last record in the table (file). Issue GOTO BOTTOM in SQL Server, and you go to the last record in the result set. Whether or not the result set contains all the records or not is another issue. If they do, then SQL server is being treated as an ISAM table. Being treated as is not the same as being an ISAM table. As a point of fact, VFP loads as much of the table into memory as it can.
>
>Even if you issue GO BOTTOM VFP does not a lot more than reading the last record. It does not read the whole table. When in a browse it might also read some near records, but it does not read the whole table.
>
>As loading into memory, I think this is a lot OS related. for a large part it is not VFP but the OS that buffers portions of the table. How do VFP views and queries compare to SQL resultsets ? I think they're very simular. Remember the filtered SQL results, issue a go bottom, and it goes to the bottom of the table while the resultset does not contain all records ? Is this ISAM or not ? I don't think that has anything to do with this.

No it is not OS related. VFP employs its own iternal memory manager. Naturally, with a large table it may not be physcally possible to load the entire table into memory.

Both view an queries require that the underlying table, which is a single file, be open. They're similar in that they return a result set, but the underlying mechanisim is very different.

With a parameterized result set from SQL server, issuing GOTO BOTTOM only affects the result set, nothing else. Issuing a GOTO BOTTOM against a VFP table, which does not have have an index set requires VFP to either physically locate it (worst case), or use the existing indexes to find the last record in the table.

>>One other difference is that with an ISAM table. Since ISAM is only capable of a positioned update, it takes at least two round trips to the backend. One to position the row, the other to actually commit the changes. An a SQL set based operation, it requires only one trip to the server, telling it to update the records that meet a specified criteria.
>
>That is just a matter where the border between the client and server is. I could do the same with a out-of-process VFP server running on the server directly. In a way the SQL server does just the same, though the database is just on the same phisical computer: It also must first read the contents of the record (for various reasons) before it can update it. Only there is no network in between. I see no big distinction between the two here.

You're making a completely invalid assumption here. You're assuming that an SQL Server database is a single physical file. It is not. It is one or more physical file(s).

Tables are made up of 8KB data pages. This contain the not only the phyical rows, but other information regarding the data page.

>>>I'll give you the tables are file based argument, but the database container itself is a container that could be compared with the one datafile a DBMS stores its information in. To me this is not as black and white here.
>
>>>How could you partually open a table ? I don't quite get what you're saying here. Both VFP and SQL have optimizing mechanisms (e.g. rushmore) that make it possible only to retrieve the records you want without sequentially scanning the table.
>>
>>Sure, that's the way SQL Server is built. Just because you add a record to a SQL Server table doesn't mean that it is physically the last record in table. SQL Server, as I recall, is page based with the pages accessed through a binary tree index.
>
>You mean clustered indexes ?

No, see above.

>Nontheless, I still don't understand what you mean by "opening a table without reading all its records" ?

You're think in file based terms. There's a lot more to this under the hood.

>>>The internal schema of a Server DBMS is ussually seperated from the external one, thus it is ussually invisible for the developers of how it is implemented. Therefore I don't see the value of if a Server DBMS is ISAM based or not. In VFP OTOH there is no distinction between internal or external scheme's: Index files, Tables, physical storage are very visible and could be accessed from VFP (or the filesystem) directly. This is both VFPs strenght as weakness: On one hand you have maximum control and flexibility, OTOH the 'encapsulation' and therefore the protection and authorisation of the VFP database is virtually null.
>
>>The internal mechanisms are extremely different. Read "Inside SQL Server 7.0".
>
>That is not the point: a DBMS can be based on ISAM, but still have the same external scheme as SQL 7. The external schema is just a layer on top of the internal one, hiding its internal schema (implementation).

But SQL Server isn't based on ISAM. It's completely different. I've given you specific points based on the fact that I've RTFM. You can't argue with these points if you haven't. If you want to find out, then buy the book and read it.