The alias mechanism allows you to treat two or more users as the same user inside a database so that they all have the same privileges. This mechanism is often used so that more than one user can assume the role of Database Owner. A Database Owner can use the setuser command to impersonate another user in the database. You can also use the alias mechanism to set up a collective user identity.
For example, suppose that several vice presidents want to use a database with identical privileges and ownerships. If you add the login “vp” to Adaptive Server and the database and have each vice president log in as “vp,” there is no way to tell the individual users apart. Instead, alias all the vice presidents, each of whom has his or her own Adaptive Server account, to the database user name “vp.”
Although more than one individual can use the alias
in a database, you can still maintain individual accountability
by auditing the database operations performed by each user. For
more information about auditing, see Chapter 11, “Auditing.”
Table 10-8 lists the system procedures used to manage aliases:
Task |
Require role |
System procedure |
Database |
|---|---|---|---|
Add an alias for a user |
Database Owner or System Administrator |
sp_addalias |
User database |
Drop an alias |
Database Owner or System Administrator |
sp_dropalias |
User database |
As of version 12.0, you cannot drop the alias of a login
if that login created objects in the database. In most cases, you
should use aliases only for users who do not own tables, procedures,
views or triggers.
