Has anyone ever come across a reason why someone would manually create a
user table incl. permission flags and not use the inbuilt user/roles
provided by that database? The only reason that stands out for me is to
make the database that bit more portable?
Thanks,
Craig.Craig, it would depend on exactly how the table in question is
constructed and used but some applications provide application based
security. The application might connect to the database using one ID
that is the database owner or has both datareader and datawriter but
via the application limit what end-users can do.
HTH -- Mark D Powell --|||Craig H. (spam@.thehurley.com) writes:
> Has anyone ever come across a reason why someone would manually create a
> user table incl. permission flags and not use the inbuilt user/roles
> provided by that database? The only reason that stands out for me is to
> make the database that bit more portable?
The database-level can be a bit heavy-handed. In our application, our
security scheme on SQL Server is dead simple. All users are added to
a group, and that group is granted execute access on all stored procedures
and select access on most tables.
Then our database includes tables to control access to application
functions, and also access to which accounts and customers a user may
see.
True, our system started its life in the days of 4.x when the permission
system in SQL Server was far less sophistcated than today. But since
our securable entities are not SQL Server entities, I can't see how
SQL Server could help us, even if we were to make a complete restart.
--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx
