>George
>
>>>The principle drawbacks of remote views are two-fold. One, if the underlying structure of the table changes, an error is thrown and the view has to be updated. Second, you can't really leverage the power of SPs.<<
>
>I feel obliged to respond...
>
>If the structure of the underlying table changes, you *may* need to alter SP, SPT and RV.
>
>If you have used SELECT * syntax in your RV then you will always see an error. If you have specified fields, you will see an error only if those fields have changed.
>
>How is this different from applications selecting/updating named fields with SPT/SP?
>
>In any case, you can pay $300(?) to buy a copy of xCase that allows you to move tables, views and data between backends without any of these issues. Recommended.
>
>As for RVs being unable to leverage the power of SPs; one might equally say that SPs cannot leverage the power of RVs. What does it mean without a business context?
>
>Sorry if I seem to have a "bee in my bonnet" about RVs, its just that they have proven such a spectacular success in my business that I cannot fathom why they are not better used by others.
>
>Regards
>
No problems, John. I believe in using them RVs when they seem the best solution and SPT when it seems best. A couple of months ago, I wrote a test program for a project, got lazy and used RVs for look up values for calculations. I've regreted ever since because the tables are still, to some degree, in flux. Had I thought harder about it, I would've used STP. Each, as Robert pointed out, has its place. It's simply up to the developer to evaluate and make the choice that seems best.

Just as I'd say, and have said, "...use the right tool for the job" when it applies to languages. I'd say the same thing for RVs and SPT/SPs.