>>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.
>
>Didn't mean to suggest that YOU were spreading FUD here, but rather this continued use of "ISAM" (as in things like 'well what do you expect in an ISAM environment' or 'you should know better than to use ISAM for ...') is disparagement that is the FUD because it looks very much like SQL Server's storage/retrieval method too.

Jim,

Appearances are deceiving. Chapter Six of "Inside SQL Server 7.0" delinates the differences pretty well, especially beginning at page 229.

I know that you weren't accusing me of spreading FUD. ISAM has its short-comings as does SQL Server. Let me give you a real life example.

I have to migrate to SQL Server from native tables. There are series of 14 or 15 systems referred to as "Efficiency Systems" (there are numerous processes and each has its own system). A couple of these have different reports that break down the same information in numerous different ways (one system has 27 different breakdowns).

In VFP, using native tables I can create a single query, passing parameters that can build the cursors used in the reports.

In a meeting earlier this week, in talking about about the migration, I mentioned the number of different reports and said, "I don't really thing that you want to have over 10 different stored procedures to return the result sets." I was looking straight at the DBA, and saw the look of horror on her face when she realized the implications of this.

The problem here is that SQL Server will not allow you to include fields that aren't in the group by clause when aggregate functions are used. In VFP, you can do this.

The best solution (especially since the code already exists) is to pull over the range of data desired, then execute a query in VFP to produce the result sets. In this scenario, there's one stored procedure on SQL Server and one in VFP to maintain, rather than 10, 15 or 20 SPs in SQL Server.