John,

>I don't have a lot of time to really get into this in the detail I would like..

>However, my comments regarding SQL where really meant in the context of using the SQL Server product for your data store as opposed to using the native VFP data storage mechansim..

>If anything, you have shown that when working with VFP data, Xbase constructs can often perform better than relying soley on SQL constructs... You will get no argument from me here.... The fact is, on SQL Server, it is often better to have a stored proc that does several intermediate operations as opposed to doing things in one big SQL statement...

This also adresses SQL-queries on SQL server. To my limited knowledge the strategy of SQL on a SQL-server is comparable with those of VFP. The intermediate results are also stored either in memory or on disk. I'm just pointing out that it would better to follow the described strategy in at least some cases.

Also note that my test seems to tell us that it less stresses the network, which indeed was an issue here. I've talked about redundant data send back by the SQL-server in end-users reports. If you'd look carefully this VFP approach would NOT have this problem because the data is combined at the client side and only downloaded from a remote site once.

>Once again, I think you are unilaterally re-directing the debate here...

not at all, you just don't seem to see the links here.

Walter,