I agree with you. PV do have their value.
Personally I use them extensively and the limitations that Mike is mentioning can be workarrounded.

A parameterised view to me is the mechanism to handle data in the same way as tables and cursors. Though I did look into CAs at one point but I did not see enough reason to buy into them. Seemed too much work for something that should be very straightforward, YMMV.

In cases where I need ultimate flexibility I can use SPT and turn it into a SPT view. Other techniques are getting the data via SPT and loading it into a view:

SQLEXEC(nHandle, "SELECT * FROM mytable WHERE mycondition","SPTCursor")
CURSORSETPROP("Sendupdates", .f., "MyView")
APPEND FROM DBF("SPTCursor")
=TABLEUPDATE("MyView")
CURSORSETPROP("Sendupdates", .t., "MyView")

This has saved my butt several times as well.

Another point not mentioned is that PV are SQL injection free, whereas with SPT or CA they tend to be much more susceptible to code injection.

However, as with all, you'll have to apply them where they make sense. Else choose for something else like SPT. Don't let the limitations of RVs limit the flexibility of your applications.

walter,


>Well, we'll have to agree to disagree. I think your admonition against PVs is unfounded. You just have developed a technique that you like and now you think everyone should use it - that does sound biased. Developing always in multiuser mode is a great thing. But having to do all querying in a certain way is just your personal preference. And to say that having different ways to query data within the same app is asking for trouble is also unfounded. As long as the techniques are used soundly, there is no reason that it is "asking for trouble." I actually edited my original comments to take out the statement that you were dissing PVs, thinking that may not have been accurate, but your reply seems to support that original comment.
>
>>Ah. I understand. IMO PVs are so common they're a defacto standard. I'm not dissing them. It's not possible to diss something abstract like a technique.
>>
>>BIAS: a particular tendency or inclination, esp. one that prevents unprejudiced consideration of a question; prejudice.
>>
>>I don't have a bias against PVs. I've got considered reasons to avoid them.
>>
>>I look for techniques which can be applied to all situations. Multi-user is a technique that can be used in all situations. Single user cannot.
>>
>>Seems to me having a system with PVs, CAs, SPT, SEEK etc. is just asking for trouble. User requirements have little to do with implementation.
>>
>>I used PVs before and even advocated them. I grew out of them in favor of SPT or CAs. The dynamic macrosubbed where clause of the view was awkward at that start, then VFP changed how it had to be done. Yuck. The whole view designer was broken for a long time. Views have limitions like the one I pointed out. They're easy, sure, but easy seldom equates to optimal.
>>
>>Lots of programmers build systems where the user cannot do their own searches (excepting reports). PVs work fine like that. I think it's wrong to limit the user like that. PVs aren't flexible enough.
>>
>>I won't go out on a limb and say they're obsolete, like Naomi did with SET FILTER :), but for new development, I'd recommend against PVs.