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

First, I don't think that "ISAM" is disparaging. It is what it is. Despite the fact that it must operate in its manner, does not mean that it is an inapproriate tool. If the application does not experience a high contention for record locks; if network security is sufficient, then I would say that implementing an SQL Server based solution may not be the best solution and that VFP's native data engine would be more than sufficient to handle the load.

I'm not spreading FUD. Record based and set based (like that better?) have their places in the world and, I believe will continue to have their places. So when I use the term, I'm simply using the most apt description I can think of.