A few directed comments...
>Mike

>
A Remote View is useful if you have a stereotyped query whose content needs to be updatable. You can use a RV just like a local table, USEing it, REQUERYING() and TABLEUPDATING() with greatest ease.
<

I guess my first question is "What is a sterotyped query? Is it something specific to RV's? As for using, I grant you that USEing a RV is a nice feature, but one that is not that difficult to simulate with SPT. As for Requerying and Updating, it is no more difficult to do those tasks in SPT.


<
You can use it in grids and databound situations without messing with sources.
<

With SPT, all you need to do is set the RecordSource. Then again, I have seen cases where folks have created RV's for design time work only - to faciliate the drag and drop benefit of the data environment. At run time however, they don't rely on RV's. The controls however, don't know the difference.

<
RV also gives you maximum flexibility in baackends- including local tables and various databases, your application does not need to know about the backend at all.
<

RV's gives one no more additional flexibility than SPT. As for local data, that is only an issue if you are doing heterogenous views. Regardless of whether you use RV's or SPT, your application does nor should it know about the back-end.


>
However, the RV filter needs to be stereotyped which means it is generally less suitable for reporting or user-specified reporting.
>

Again, what does stereotyped mean in this context? As for user specified reporting? I am not sure any tool fits the bill for that. i.e., regardless of whatever you do, you will need to step outside the box a bit. Given a report template, one could easily create FRX's on the fly. If however, the criteria can change, that too should fit in a finite universerve; addressable with parameterized queries.


>
If your filter has a defined set of criteria that must be specified, RV may be possible. However I'd be inclined to use SPT to gain maximum flexibility. It's hard to say without knowing how you want your filter to work.
>

Personally, I think SPT gives more flexibility, but not for these reasons. Both are equally adept at parameterized queries.

>
A backend Stored Procedure is probably not a great option for a variably filtered query.
>

Why? Please explain..


>
I guess there is no "always right" answer, a lot depends on business issues as well including whether you have different customers wanting to use different backends including local tables, and your budget.
>


When you say different customers and different backends- doesn't this stray into the shrinked-wrapped software world as opposed to specific custom software for a specfic customer?

IMO, the budget should be a non-issue for whether to use RV's or SPT. In the long-run, RV's don't save you work, and hence, don't save money. Granted, if one does not know how to use SPT, that is a separate issue. In the short-term, it may appear like a money saver. However, I am inclined to think that money gets poured down the drain when issues of maintainenance start cropping up.


John... I read what you saying, however, I don't understand the reasoning you are employing to come up with these conclusions. Even where you come out on the side of SPT, even I, the staunchest of SPT supporters here, would not trot those arguments out. As you may recall, I did not because of their weakness. On one hand, it is true that SPT is more flexible. However, that is a conlclusion that must be supported with a credible argument. Accepting parameters is not a strength as far as compared to RV's as RV's can perform parameterized queries as well.

As for knowledge about the backends, ease, lower cost as implied through the budget reference, I see the argument you are making, however, I don't see an adaquate basis of backing up those arguments...