JVP

>>As for the only guage of usefulness is in knocking down the alternative, I don't see the merit in that at all. <<

Well, you're "knocking down" the whole basis of scientific proof which is the "hypothesis" where you set out to prove something is not true. No matter how many times it *is* true, it is the negatives that matter and by their absence eventually "prove" the hypothesis to a degree of accepted probability, or disprove it by occurring.

There is nothing wrong with examples. A verified example can "disprove" something but an isolated positive example is not much use, especially if it is unaccompanied by "context" which, with respect, is again the case with your current example.

>>My point can be further clarified that in the end, the same amount of work occurs. You can spin through the parameters on the client, and only send what has changed in a client-side rendered SQL Statement. In this case, you have the overhead of checking parameters and building a SQL String.<<

I accept that building SQL for SPT may be a considerable burden if you are using extra code to do it. But we're I'm talking about RVs and SPs. I assume you are not talking about passing a partial parameter list to a SP and writing code at the server end to manage that- a maintenance and performance risk, I'd say. Certainly I have never heard it suggested that it takes the VFP client too long to generate and send the RV update. I'm not sure what you are saying.

>>Or, you can use an efficient object - such as the Command Object and work with a collection of parameters. Not string concatenation here. No type checking involved as is the case when you concatenate strings. No string passing. Rather, I am passing an object. I suppose I could pass XML as well. XML would be a better alternative to a concatenated string.<<

Different topic/s.

Regards

JR