>I'm aware of the cursors on SQL-server, but as far as I know this is not a ANSI 92 feature, meaning that it may be available to MS SQL-server but not in any other.
>

So...it is a T-SQL feature. Scan, Replace, Locate are not ANSI 92 SQL commands, but I bet you use them. The fact is, you CAN do row by row operations in SQL Server... I really don't understand the point you are making here Walter... The discussion here is only germain to SQL-Server. However, I would bet you can do similar operations in P/SQL (Oracle). I think you are trying to stretch the argument here a bit.

>Both. Using ADO to solve this problem is fine, but requires an extra layer. As I'm not that familiar with ADO, i don't know how this affects performance.
>

I think the issue again is that you are not familar with too much outside the VFP world. Clearly, you were not that familar with row by row operations with SQL Server cursors. Once I brought out that example, your next attempt at shifting things was to then say "it might not be avaiable with other backends.." The fact is Walter, everything you are expounding on here can be done, quite easily I might add, in something other than VFP.


>I did not say that. I did say that VFP performs A-synchronous executing also. If you open a large table (even over a WAN) it only buffers a small portion of <
the table, the rest is requested whenever neccesary.
<

No... You cannot open a table in an async fashion. Until the info that needs to be rendered to the client is rendered, you will not get control back. On the other hand, I can send a query to SQL, and get immediate control back.

<
BTW how would you handle SQL queries where different tables from different database on different site (connected with a WAN) are involved ?, especially whgen these queries are ad-hoc and can't be pre-determined ?
>

If I can connect to the servers, queries are not an issue. Do you think this is a problem in SQL-Server. Running queries accross databases on the same server is easy. Accross different servers.... I probably would not allow ad-hoc queries for that. In fact, I would not allow ad-hoc queries period... Rather, I would get the requirements and build the appropriate stored procedures. In large scale environments, you really like to keep ad-hoc stuff to a minimum. Fact is, most stuff people need - 80% of it is repetititve. And for the complex stuff, end-users don't have the expertise to put those queries together anyway.
Ad-hoc querie capability has more of a perceived value than a practical value. Most queries - in reality - are not ad hoc.


>You've got to be carefull here john, you would probable mean SQL-server 7. Since I don't own SQL server 7, you are probably right, but my graduation project was to ivestigate the differences between record oriented and set oriented databases, So i'm well aware of the features generally available within any SQL-server variant as well as the relational model theory.
>

That stuff is great from a theorhetical standpoint. I think you may have a grasp of theory. However, it is clear you have not REALLY done this stuff. If you have, you would not make the comments you are making. Heck, you don't have SQL Server 7, and yet, you stand here making comments about what SQL can/cannot do, and why VFP appears to always be a better choice.

I understand the need for self-validation here. However, I have an equal need to set the record straight....

Get SQL Server, work with it, and then come up here and comment on its capabilities.....

Once again, too much anecdotal knowledge and theory, and not enough practical knowledge... <s>.....