SNIP
>
>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.
>
>One can treat SQL Server tables as ISAM, but that could be a significant design mistake depending on the underlying nature of the table(s).

George,

Don't we know, just from the way FP/VFP operates, that we do not have to retrieve all of the records!? I mean Rushmore retrieves only .CDX parts and then directly retrieves only those records that are relevant.

To me, in the absence of ever having seem (remembered?) an "official" definition, I see "file based" as meaning that specific tables are each stored in specific tables. SQL Server(?) or ACCESS (for sure) stores tables in its own 'structures', differentiating them from "file based".

Someone once wrote that VFP is file-based while SQL Server is set-based. My argument with that is that VFP is, really then, BOTH. Regardless, if SQL Server or anything else is to be differentiated from VFP as being "set-based" then I think it is fair to say that either term has little or nothing to do with actual storage methods or access mechanisms.

My issue concerns the intended denigration of FP/VFP (xBase generally) by referring to it as "ISAM". I don't see a whole lot of difference, other than in the software itself, between VFP and SQL Server. Storage/retrieval-wise, they are closer than they are apart.

In summary, they are both "ISAM" or they are neither "ISAM", so disparaging VFP by calling IT (alone, in the context of SQL Server) "ISAM" seems really off-the-mark to me and more FUD than fact.


>
>Snip