Agreed, John.

>> Where multiple developers are hitting a database from different tools, some would advocate SPs. Others would advocate a middle tier. Both can be argued by a sophisticated developer <<

FWIW, I believe in using tiered development unless there are good reasons (usually hard for me to come by though) not to for a specific task or project. So for me, there's pretty much always a middle-tier (vs. having business logic in the UI or UIs). Much of what I do in my current position BTW, coding wise, is to rescue business logic from the command buttons of poorly-developed VFP forms, refactor the code, and then make the logic available through middle-tier components to both the original app and new ones, including web sites.

But I also believe that a good middle-tier design allows for the data to be accessed and updated through any of the available methods, including SPT, SPs and (in the case of VFP) RVs. So, again FWIW, I like the combo of middle-tier business logic that uses simple CRUD logic for data access and I prefer the CRUD code to be in SPs even if it's JIC we later want to hit the database from other tools (i.e., it's not planned initially). But as you say, certainly not to the point of being a monomaniac -- I have CRUD code in many of my middle-tier classes too -- insert smart*ss comment re: "crud" here *s*.

And in fact, in the case of using Oracle, I'm not man enough *s* to want to do much in SPs at all, so *all* of my Oracle data access code is in data classes that are fairly tightly coupled with the corresponding business classes from the middle tier -- in that case, I decided that it was easier for me to have my web developer use COM components created from the data-access classes that I also use in the big VFP app than for me to migrate all of the VFP data-access logic into PL/SQL. This would also allow me to more easily move the data from Oracle to SQL Server at some point, if I could convince my company execs to put a higher priority on that data conversion project.

Thanks for the discussion, even though we strayed a bit from overloads. :)

Kelly