>>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?


George, though you are perfectly right on the above, IMO you begin at the wrong end ;)
As how you present it, it will be hard to go from SQl-based to native tables, and that is right of course. However, we wish to go from native tables to SQL-based. In the end your are STILL right as long as we all see that what we wish for is far more easy than the other way around.
I commented on this because I myself read your above lines wrongly. IMO the below just IS applicable. If you don't agree upon my comments on the above lines, please explain a bit further, because appearently I then don't understand.


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