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

Where we talking about a SQL-server issue or talking about SQL in general ? If SQL-server specific then I'would appologize. What about setting relations, seeking records based on existing indexes, setting filters ? I can't imagine that SQL-server as just as record based as VFP.

>>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 thought we were talking about VFP solutions, whether it was native VFP or VFP in combination with SQL-server. As for the other arguments we discussed this before in the former thread.

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

ah. you must mean background fetching. yes sorry for my confusion, I did confuse it with batching . yes that's not possible in VFP. Though I think you're overvalueing this feature. In al lot of cases you still have to wait before you can do anything with the data.

>BTW how would you handle SQL queries where different tables from different database on different site (connected with a WAN) are involved ?, especially when 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.

IMO queries among different server are adhoc in most cases. If not, it might be a better choose to replicate the needed data to the local server. The point i'm trying to make here that if SQL-queries are ran trough different sites there are parrallels to draw in the way VFP executes the queries. So much for the performance gain. Remember that the query optimizer (at least in version 6.5) is fairly incompetent when it comes to distributed (and heterogenious) environments.

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

Seriously I've done this stuff. I don't own a copy of SQL server 7, but own a version 6.5.

>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 think you're misinterpretting my comments, john, I'm not saying what you think i'm saying (as the case was in the former thread). I'm certainly not saying that SQL-server alway delivers less performance than a VFP engine, even on a WAN. You are the one making discussable statements about the performance of SQL-server. I'm only stating that this issue is not as simple as you might think.

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

I have the need to straighten things out correctly and precise. You were not saying this in a precise way; therefore I jumped in.

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

As i said, I own version 6.5 and have done work with it.

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

Once again you make dangerous assumptions.

Walter,