Charlie

IMHO this is a severely circular argument. People apparently don't like RVs because on the "read" side, a RV "might" send an entire SQL command that may be pretty big, across the wire. That's assuming you don't use select *.

Then on update the same people are willing to send each and every field back- hardly an advertisement for efficient use of bandwith and unnecessary extra work for the server that has to update every single field even when only one has changed.

What about field-level contentions? Modern (for example) operating theatre apps rely on multiple users updating same-row fields every few seconds and not overwriting each others' work with stale material. Updating every field every time creates a contention nightmare for such an environment, slowing notoriously critical clinicians down with stupid contention decisions they do not have time for and creating still more cynicism about IT. RV or SPT solves this completely.

As for the "performance" of optimised SP vs SQL: I refer to the existence in odbc of the "create temporary stored procedures for prepared SQL statements..." option that, apparently, speeds up passed SQL if you use stereotyped parameterised queries as RV does.

At least, this was true prior to SQL 7 where such tactics apparently did make a difference. But this may not be the case with SQL7 whose "direct" as opposed to "prepared" SQL execution may be very similar.

No I did not just make that up. Quoting from the SQL7 docs:

< start quote >
Direct execution is commonly used by applications that build and execute statements at run time and is the most efficient method for statements that will be executed a single time. Its drawback with many databases is that the SQL statement must be parsed and compiled every time it is executed, which adds overhead if the statement is executed a number of times.

When connected to versions of SQL Server earlier than 7.0, direct execution should be used:

Whenever a statement is likely to be executed fewer than four times.
To call stored procedures.

SQL Server 7.0 significantly improves the performance of direct execution of commonly executed statements in multiuser environments. For SQL Server 7.0 applications, using SQLExecDirect with parameter markers for commonly executed SQL Statements can approach the efficiency of prepared execution.
< end quote >

This seems fair- after all, VFP's own execution of macro-substituted SQL is fast+++ once the parsing engine has loaded. SQL just isn't that complicated, if that's all you're doing.

So: at least some effort to determine the "facts" rather than "slogans" is urgently needed IMHO. The "obvious" principle that I was always prepared to accept, that SP is faster, may no longer be so "obvious" in every case- an argument for the "why?" that is supposed to characterise a practical profession. We need to ask it.

As for the "Emperor's clothes"... if the Emperor is naked, or turns out to be wearing only a loin-cloth rather than the sumptuous robe others describe, I claim credit for noticing!

Regards

JR