>>I am not sure if I like the SP approach. Also, I am pretty heavily into VFE, and his data classes give [me] similar functionality, granted I think they need a bit of work and refactoring, but they suit my needs today.
>>
>
>
>Is it that you don't like using stored procs, or because they don't fit into a VFE application? Actually, if your rewire the VFE cursor classes a bit, they can easily get their data from stored procs as opposed to remote views.

A little of both. With stored procedures, or even SPT for the main maintenance type forms I would loose the use of DBCX, which gives me the ability to give the user alot of control over the application.

Also, as a non-dba person, I would rather maintain the querys that I am using in the Ap, or Middle tier, using either remote views, SPT or even ADO I can acomlish that. Since I mostly deal with a shinkrapped ap, that has it own set of data I think the maintenance is easier this way. If I were writting aps against a data warehouse type server I do think the SP approach protects your ap from back end changes.

>
>Stored Procedures provide the most robust C/S architecture. It provides for a more secure environment. It provides you with the ability to modify various data-centric aspects of your application without having to recompile your application. And, in the realm of C/S applications, it is regarded as a best practice....

So we always follow the crowd, go with the flow? Doesn't sound like the Weasel hunting JVP we know and love! (I'm using VFP ain't I?)

BOb