>George,
>
>>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?
>
>I understand that a total transparency is very difficult, if not impossible:
>I could handle a whole SQL-table by using a remote view (with background fetching) though the indexes attached are unreachable, so this makes a difference, yes. A significant one ? Maybe..

As with all things, it depends on the circumstances.

>for validating the contents of tables, there are different approaches, not always applicable to both, but certainly there are coiches which are fairly simular. For example: you could let the business rules fire at the database level, which for both databases work fine.
>
>Frankly, if I think of it, I already use P-views in instances where I would use then in SQL also. In instances where I want to use native table, I see an equivalent in remote views with background fetching or fetch as needed (which by the way VFP also does with its native tables)
>
>
>>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.
>
>Again, yes there are differences, but I don't see a problem in raising an error in these cases. I really see possibilities to close the gap of the design paradigms.

But they're fundamentally different at their respective core (unless, as I mentioned) you're using a p-view.

I for one wouldn't like to see the above differences changed. I can still use one query (rather than 14 or so).

>>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.
>
>but the processing is always done on the ODBC client, not the location where it is stored. IMO, we would gain much, if it only where posible to let the processing done on the server instead of the client. It's hard for me to imagine that this would be a difficult task for the VFP team to implement. In this way we really would have a VFP-xBase server, (though its comunication language still is SQL), which is capable to overcome network bandwidth issues. This would avoid a lot of WEB, DCOM implementations.
>
As I pointed out earlier on, without some additional costs on the server, you still have problems (for example, latency causing table corruption). If you're going to spend the necessary money to have the appropriate hardware (RAID drives, etc.) then the extra expense of SQL Server is worth the cost, simple you get things like the transaction log along with it.

Fox native tables are made for the desktop. If folks need a backend server, then get a real one not a pseudo-one.