Paul, I think I see your point - where I work the lines blur a little too, and it wouldnt be out of the question for me to need to give a developer this kind of access. The alternative might be for me to do it, but then I'm the bottleneck.

Jamyer, I don't disagree that this might not qualify as a "best practice", but I'd say based on the changes in SQL2K MS must have run into a lot of people that needed security to be a bit more granular?

Sometimes you just need a solution. For example, where I work I needed to have 2 people from a different part of our IS team be able to create databases on two servers, enable replication, and a few other things. It ended up that to really get it done right without me having to go behind, they needed SA access. Not a great plan - I trust them not to touch things they aren't supposed to, but the fact is with that kind of access mistakes get costly. The alternative I ended up fielding was an app that would connect as SA and do the tasks - they only get that access via the app. Could I have done this with a job? Maybe. Honesty didnt try since I needed an interface anyway.

My point is that in some cases, we have to step out of the box. Because of SQL limits. Business requirements. Politics even. As long as we KNOW the risks and do what we can to reduce them, you do what you have to do.

One of the great things about discussions like these is when a junior DBA or developer stumbles across it, they can find the dissenting opinions close by...giving a valuable perspective I think.

Andy