william stacey [mvp]

I still don't know what you point is. Bad code is bad code. Some people
may write bad or inefficient code, some may not. All I was saying is that
you can not just flat out assume that because you can now write stored
procs/functions in c# or VB that that will change everything. Naturally,
there is a broad range of uses for a DB. Many are single use or turn key
where the DB is only needed in the first place for the application. Maybe
they are upgrading from a simple XML file or Access or something else. On
the other end is your Enterprise DBs running on big AIX machines or
something with a staff of DBAs. I think that is more the scenario you are
talking about. In this case, then yes you need to be really careful as
other production stuff is also involved. But the DBAs need to do that
anyway and is just part of doing business. They have to assume people will
try stupid things and protect the resource. That is what ref integrity,
triggers, and so on are for. As for your Selects, people have been able to
do this from the beginning, so what is changing? If a DBA wants to tie
everything down, then allow only SPs (that the DBAs write) and no external
selects. No new issues here that I can see.

--
William Stacey [MVP]