Not sure how you got that out my comments. I said I had no control over the application code only the database code. I am not a manager. I send articles to the other developers, try to educate them, complain repeatedly to management and constantly push for better development process.
> What I find hard to understand is that you really don't give > a **** about the application your procs are part of, as it > seems. That's part of the problem: procs aren't a separate unit on a > different planet controlled by another company, they're part of > the application as they make up a (great) part of the functionality > which is formed by the application. I can't really understand what you said in the other part of your post. I don't really think there is any value discussing this topic anymore. I don't believe there is one solution for every application and if that is what you believe that is fine with me. I am pretty sure that everyone got the general meaning of my statements. If you are just looking to continue an argument I would suggest looking somewhere else as I am growing tired of arguing and this thread. Tim Flory Sr Programmer Analyst Phone: 216.464.2244 ext. 229 www.medquist.com This electronic mail transmission contains confidential information intended only for the person(s) named. Any use, distribution, copying or disclosure by another person is strictly prohibited. If you are not the intended recipient of this e-mail, promptly delete it and all attachments. "Unmoderated discussion of advanced .NET topics." <[email protected]> wrote on 09/15/2005 09:31:02 AM: > > Sure it does since the developers have to submit their stored > > procs to me to be applied ;-) I have no control what they do > > in their crappy code but I have almost total control over > > what gets applied to the database. If I allowed dynamic SQL > > in my stored procs (which requires permissions to the > > underlying tables) then why would I care if they put it in > > their business objects, front end or whatever. Where there > > is no separation of duties and no control you are just about > > guaranteed to have crap regardless of your beliefs on where > > the business logic goes and the value of stored procedures. > > though what's your point then? Have only skilled people in > your team who know what they're doing? Sure, but that's generic. > :) > > What I find hard to understand is that you really don't give > a **** about the application your procs are part of, as it > seems. That's part of the problem: procs aren't a separate unit on a > different planet controlled by another company, they're part of > the application as they make up a (great) part of the functionality > which is formed by the application. > > > Yes, while you are technically correct that it is > > parameterization that prevents SQL injection I am pretty sure > > you understand the point I was making. It is great that > > there are many intelligent people on this list who can argue > > so well, but I have found some of the hair splitting and nit > > picking that goes on here detracts from the value of the discussion. > > yeah, all fine but this is of course BS. Mentioning 'Dyn. > SQL is vulnerable to SQL injection attacks' and then later on > saying that you meant a corner case (as in: bad practise goo > generated only by vs.net or by an unskilled developer) why mentioning > it at all? Of course concatenating values into query strings isn't > good, but that doesn't mean dyn. sql is vulnerable to injection > attacks. > > FB > > =================================== > This list is hosted by DevelopMentor® http://www.develop.com > > View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
