>>If you use SPT with stored procedures, those stored procedures will be useful should you ever switch to another front end, whereas RV's and CA's will not be.

That's true, but there's a flip-side: using SP locks you in to that backend. In my case I had customers using SQL Server, Oracle and Cache as a database, followed by MySQL. Recreating RVs programmatically against each backend (and later using xCase) was all we ever had to do. Writing SP for each backend would have been quite a hurdle, especially since MySQL didn't have SP at the start. When I last looked, SSCE didn't have SP either. Might have now.

In practice we found ourselves using SPT, RVs, SPs and Oracle Views (which are a very interesting beast indeed). We never found a reason to cleave to just one. Over the years I have noticed that many gurus weren't impressed by RVs, preferring to use the techniques commonly seen in other tools. Doesn't matter any more since the market is always right, but that's something I never understood.