On 23 January 2011 17:40, Greg Keogh <g...@mira.net> wrote: > I certainly can read and write, but sadly, I can't execute Stored > Procedures with my new account. So my simple fix doesn't work as easily as I > hoped. > > > > Rather than futz around for hours on this and start altering permissions on > procs, I was wondering what others have done in similar situations. Does > anyone else have nice tricks for making connections with more sensible > permissions? >
What we have settled on as the 'best way' to do this is to create a number of database roles as a part of your application. Let's say that you have two levels of security wrt to the database, admin and internet-user. You create two roles one for each. Secure your securables (stored procedure execute etc) against those roles based on appropriateness/your design. Once you set that up, you can add .\gregk to both roles on your dev machine. Once you move to production you can add the "www.example.com" account to the internet-user role, and maybe an AD or local SAM group to the admin role. So basically you're defining the levels of access back to the data tier as a function of your database design, while the actual user accounts that go into those roles are decided at deployment time. -- *David Connors* | da...@codify.com | www.codify.com Software Engineer Codify Pty Ltd Phone: +61 (7) 3210 6268 | Facsimile: +61 (7) 3210 6269 | Mobile: +61 417 189 363 V-Card: https://www.codify.com/cards/davidconnors Address Info: https://www.codify.com/contact
