Dear JVP

>>Then why did you bring up Oracle and IBM then???

Because you had lots of ad hominam slurs for my apparent "stupidity" in moving to Java; I pointed out that I had good company in the form of Oracle, IBM and MS, presumably you think they were all dullards as well. Your response was to try to tell me how to develop using Oracle. Some people call this "flight of ideas".

>>When it comes to having facts - and requiring others to do so - you can put me first in line. I'll be the first one to call somebody on the carpet if they are espousing expertise based on anecdotal experience.

Whoa. By "anecdotal experience" do you mean "personal experience reported by anybody except me", since that is what anecdote is? Are you saying you will pull people up if they quote their own experiences?

>>Maybe someday, we can revist the whole RV vs. Stored Procedure Debate...This time, we'll take it to Oracle instead of SQL Server... < bg >...

Well, my position remains that SP, SPT and RV all have a place depending on particular need; I still don't agree that a "SP vs RV" debate makes sense. As a reminder, here's what I said in the wiki page I made at the time, bearing in mind this was 2 years ago:

"As always in this life, there are few arbitrary answers when one asks "what is best" and the right approach varies according to circumstance.
New developers can get underway most quickly using RVs and generic designer tools.
If developers perceive that cross-database function is an advantage, RV’s are likely to remain a preferred option.
For large scale "batch entry" missions, SP’s are an obvious choice, offering best possible scaling.
For applications where viewing and massaging of existing rows is a larger concern, the less efficient update of a SP may be significant, especially in a WAN environment or where rows are large. It may be wise to at least test RVs or SPT.
For larger applications, the RV "locking" issue is currently significant. To avoid this limitation, certain strategies are available but they all add complexity. Developers must balance the extra complexity against whatever RV advantage makes them consider RV.
For applications where various users may simultaneously alter different values in the same row, SP is the least suitable option.
Pure performance is no longer an "obvious" compelling differentiator.
Finally: any suggestion that developers must select and stick to just one option is not based on business or technical proof. Indeed, sophisticated developers can consider combinations of techniques. For example, cursors created using SP or SPT can be converted to updatable cursors using sqlsetprop() commands, to make use of the more efficient RV update facility, with a relatively small amount of code at the client. Such strategies allow developers to harness the best of all the available techniques, using VFP’s flexibility and power to yield outstanding results that may be much harder to achieve with other development tools."