>Again it depends on the situation. SQL is a set oriented language (at least it is suposed to be as it is positioned as an implementation of the relational model) where as xBase languages are primarely record oriented (though SQL is supported (sometimes in a limited way)).
>

Yes, SQL Server is a set oriented. However, you can perform many row by row operations with server-side cursors, I do it all the time....

>The differences between the two approaches are huge. Within the relational model there is no mechanism to browse trough the resultset (though there are limited ways within SQL) whereas xBase languages have a record pointer to point to the current record.
>

In a SQL-Server stored proc, I can get an intermediate result set, and scroll through it just like a do in a VFP DBF....

>The differences between the two mechanisms become clear when using a hierarchy of tables linked to eachother with the SET RELATION command (thus suing the indexes efficiently) to get the data you want. On top of that you can filter tables within the hierarchy to provide a very powerfull way to reach the same goal as you try to do with JOINS in SQL. Difference here is that the Xbase solution of using a hierarchy is many times faster than using the SQL equivalent (yes i've tested this), and requires less memory (there is no query to be executed) to get the data you want, especially when the hierarchy involves lots of tables (thus many joins in SQL).
>

I would like to see the notes and data of your tests....

In VFP, you scroll through records. In C/S scenariios, you don't do this. And if I need to, ADO provides a wonderful mechanism called a shaped recordset, which behaves like the set relation mechanisim in VFP.

Did you do your tests on a WAN, or a LAN??? Big difference.....

>Another advantage of this solutions is that it's pretty a-synchronous. The relations are searched whenever you skip to another record and the records used in the whole hierarchy are only requested from the file when needed, especially when different tables are distributed on different sites over a WAN.
>

And we don't have async processing with SQL-Server? Open a VFP table over a WAN, and watch how Async, excuse me SYNC it is.....

>Of course when it comes to analyzing/transforming data out of few tables (comming from one site or connected with a high speed connection), SQL is many times faster than any xBase solution (MAX(), SUM(), AVG() clauses in combination with GROUP BY/HAVING clauses)
>

OK...

>Another parameter is the Server capacity issue. I've seen too many cases where the server where SQL was running on was hopelessly underequiped (Small to medium large companies). The workstations often had a faster processor than the server (though this one mostly has more internal memory). In this cases a local database engine should provide far better performance because each workstation has it's own CPU and won't burden the server CPU when several workstation are executing fairly heaving SQL commands.
>

Gotta have the horses... I agree with you here...


>That's why I love VFP. It can use both of technologies even if one table comes from a SQL - server, the other is stored on the local network and the third is accessed through a WAN.
>

I love VFP too... However, SQL has some capabilities that you are not aware of....

Too many folks take a VFP mindset when working with SQL. And of course, they say it is slow. Why? Fetching 10,000 rows over the wire, when in VFP, it is almost instantaneous. I want to put my fist through a wall everytime I see stuff like this.

You need to understand a tool, and use it accordingly.

Most folks up here, and in the VFP community in general, don't understand SQL Server enough to properly conduct a realistic comparision...<s>