>>>2. Changing program logic and having to re-distribute the EXE to every client machine.
>
>In the context of this example, where you advocate replacing SQL via SPT/RV with SP, I challenge you to prove that using RV or SPT makes "changing program logic" more likely than with SP.
>


I am not going to entertain your "more likely" challenge becuase it is such an open-ended beast. Also, I don't know the specifics of "this" example. That said, I will give you a couple of general hypos:

Lets say you want to implement an audit trail. If you use stored procs, the only place you have to change code is on the server. If you render sql from the client, you have to change the EXE and re-distribute.

For another example, lets say you have a complicated query. You have two ways to do it. One way involves downloading more data than is necessary on the cleint and munging the data on the client to yield a separate resultset. The other way involves a SP that returns only the data required. A SP in this case yields less complex client code.

More logic pushed to the server yields simpler/more maintainable client code. RV's are a Fox-only beast that keeps you in Fox. SPT is fine - when it is calling SP's.

Obviously, this all could result in problems if one relies on the billable hours involved in rebuilding and redistributing EXE's....< bg >...

If you work with server data, you are not doing things as effectivevly and as efficiently as possible if you render SQL from the client and/or use RV's. And...to get RV's to work in any reasonable manner, in any scaleable manner, it requires a good deal of work. RV's tie and couple the client app too closely to the underlying database. Using SP's, I can implement all sorts of database changes without "releasing" them to the client.

Sorry JR - I am not going to get into another one of these "lets justify the use of RV discussions" with you... It is a way you chose and a way you will defend. Just because you have had some success, it does not mean I have to concede the point that it is a suggested alternative.





>It is interesting that answers fell into 2 categories; those saying privileges were the problem, others saying SP would solve the problem. The problem was a privileges problem. If privileges are screwed up then things don't work.
>

Right...it is a priv. problem. And....it is far easier to maintain a single exec priv than sep priv's for insert, update, delete, and select.