>Hi George,
>
>>Since I assume you're referring to me in the above, just a short response. My statement was that designing for a backend server as opposed to native tables requires a different design paradigm. Unfortunately, there are (apparently) some folks who don't realize this and try treat the backend in the same manner they did native tables. So, in short, I agree whole heartedly with the above.
>
>But the real question is: Why is it a different design paradigm ? And what can we do to close the gap. I know this is difficult stuff that is difficult to solve. However, I'm convinced that it can be done a lot better than it is now. Personally I see much to gain on the subject of transparency, which is not neccesarely is the fastest option, but since when is SQL always the fastest option ?
>
>For example why can a SQLEXEC function return a cursor, while the VFP language is not capable of doing this. Why can't we create remote views of VFP data (not using SQL server as middleware) ? I can hear you say XML, but that really the implementation glue that should be transparent and not visible to us developers IMO when it comes to returning data from VFP components.
>
Walter,

It's a different design paradigm for a couple of reasons. Basically, in most instances, when you deal with SQL Server you're dealing with a sub-set of the table. Unless you're using a parameterized view of a VFP table, you're dealing with the entire table, and its indexes. As a result, assuming you wish to validate the contents of one table against another, and/or for business reasons, have to pull some information in from another. Typically, working with VFP, you'd simply have an index based on the search criteria and use that. With SQL Server, you may have a variety of choices: Parameterized view, index the entire cursor after retrieving it, use LOCATE, or something else?

There are other considerations. For example, I have many reports that use the results of an SQL Select statement to print their data. In Fox, I can create a single query that returns the data I need. Due to the nature of the query, I can't create either a stored procedure in SQL Server or create a single SPT string to do it. The problem is that SQL server (up to version 7.0), when dealing with aggregate functions, any column that is not being calculated, must be part of the group by clause. IOW, while the following is legal in Fox, it isn't allowed in SQL Server

SELECT Column1, Column2, SUM(Column3);
 FROM Table;
 GROUP BY Column1

As a result, I have that problem to solve and have to design accordingly.

To answer your second question, the ODBC driver is sending back the information in a way that VFP understands. You could place the VFP data on a dedicated backend server and acccess it via ODBC.