Artykuł
07/26/2011

ALTER autoryzacji (Transact-SQL)

Zmienia własność zabezpieczany.

Ikona łącza do tematu Języka Transact-SQL składni konwencje

Składnia

ALTER AUTHORIZATION
   ON [ <class_type>:: ] entity_name
   TO { SCHEMA OWNER | principal_name }

<class_type> ::=
    {
        OBJECT | ASSEMBLY | ASYMMETRIC KEY | CERTIFICATE 
    | CONTRACT | TYPE | DATABASE | ENDPOINT | FULLTEXT CATALOG 
    | FULLTEXT STOPLIST | MESSAGE TYPE | REMOTE SERVICE BINDING
    | ROLE | ROUTE | SCHEMA | SERVICE | SYMMETRIC KEY 
    | XML SCHEMA COLLECTION
    }

Argumenty

<class_type>
Jest klasa zabezpieczany obiekt , dla którego właściciel został zmieniony.OBIEKT jest ustawieniem domyślnym.
entity_name
Jest nazwą obiekt.
principal_name
Jest to nazwa podmiotu, który będzie właścicielem obiekt.

Uwagi

ZMIENIA autoryzacji można zmienić własność każdy obiekt ma właściciela.Własność podmiotów zawartych w bazie danych mogą zostać przeniesione do wszelkich głównegopoziom bazy danych.Własność podmiotówpoziom serwera - można przenieść tylko do serwera -poziom podmiotów.

Ważne:
Począwszy od SQL Server 2005, użytkownik może posiadać obiekt lub typ, który jest zawarty w schemacie własnością innego użytkownika bazy danych.Jest to zmiana zachowania z wcześniejszych wersji programu SQL Server.Aby uzyskać więcej informacji, zobacz Oddzielanie schematu użytkownika, OBJECTPROPERTY (Transact-SQL) i TYPEPROPERTY (Transact-SQL).

Własność następujące podmioty zawartych w schemacie typu "object" można przenieść: tabele, widoki, funkcje, procedury, kolejek i synonimów.

Nie można transferować własność następujące podmioty: połączone serwery, statystyki, ograniczenia, reguły, ustawienia domyślne, wyzwalacze, Service Broker kolejki, poświadczenia, partycji funkcje, schematy partycji, kluczy głównych bazy danych, usługa główny kluczi zdarzenie powiadomienia.

Nie można transferować własność członków zabezpieczany następujących klas: serwer, logowanie, użytkownika, rola aplikacjii kolumna.

Opcja właściciela SCHEMATU jest prawidłowa tylko podczas przenoszenia własności zawartych w schemacie obiekt.WŁAŚCICIELA SCHEMATU przekaże własność obiekt właściciela schematu, w którym się znajduje.Tylko jednostki klasy OBJECT, typ lub KOLEKCJI SCHEMATU XML są zawarte w schemacie.

Jeśli miejsce docelowe obiekt nie jest bazą danych i obiekt jest przesyłany do nowego właściciela, zostaną usunięte wszystkie uprawnienia do miejsce docelowe .

Przestroga
W SQL Server 2005, zachowanie schematów zmieniono z zachowaniem w starszych wersjach SQL Server.Kod, który zakłada, że schematy są równoważne użytkowników bazy danych nie może zwracać poprawnych wyniki.Stary widoki wykazu, łącznie z sysobjects, nie powinny być używane w bazie danych, w którym następującego DDL kiedykolwiek użyto instrukcji: TWORZENIE SCHEMATU, ZMIANY SCHEMATU, DROP SCHEMATU, TWORZENIE UŻYTKOWNIKA, ZMIANY UŻYTKOWNIKA, UPUŚĆ UŻYTKOWNIKA, TWORZENIE ROLI, ZMIENIĆ ROLĘ, UPUŚĆ ROLI, TWORZENIE APPROLE, ALTER APPROLE, DROP, APPROLE, ALTER AUTORYZACJI.W bazie danych, w którym dowolne z tych oświadczeń ma kiedykolwiek użyte należy użyć nowych widoki wykazu.Nowe widoki wykazu pod uwagę oddzielenie podmiotów i schematów, które wprowadzono w SQL Server 2005.Aby uzyskać więcej informacji o widoki wykazu, zobacz Wykaz widoki (Transact-SQL).

W SQL Server 2005, zachowanie schematów zmieniono z zachowaniem w starszych wersjach SQL Server.Kod, który zakłada, że schematy są równoważne użytkowników bazy danych nie może zwracać poprawnych wyniki.Stary widoki wykazu, łącznie z sysobjects, nie powinny być używane w bazie danych, w którym następującego DDL kiedykolwiek użyto instrukcji: TWORZENIE SCHEMATU, ZMIANY SCHEMATU, DROP SCHEMATU, TWORZENIE UŻYTKOWNIKA, ZMIANY UŻYTKOWNIKA, UPUŚĆ UŻYTKOWNIKA, TWORZENIE ROLI, ZMIENIĆ ROLĘ, UPUŚĆ ROLI, TWORZENIE APPROLE, ALTER APPROLE, DROP, APPROLE, ALTER AUTORYZACJI.W bazie danych, w którym dowolne z tych oświadczeń ma kiedykolwiek użyte należy użyć nowych widoki wykazu.Nowe widoki wykazu pod uwagę oddzielenie podmiotów i schematów, które wprowadzono w SQL Server 2005.Aby uzyskać więcej informacji o widoki wykazu, zobacz Wykaz widoki (Transact-SQL).

Należy również zauważyć:

Ważne:
Tylko niezawodnym sposobem znalezienia właściciela obiektu jest sys.objects wykazu widoku kwerendy.Tylko niezawodnym sposobem znalezienia właściciela typu jest użycie funkcjaTYPEPROPERTY.

Szczególne przypadki i warunki

W poniższej tabela wymieniono specjalnych przypadków, wyjątki i warunki, które mają zastosowanie do modyfikacji autoryzacja.

Klasa	Warunek
BAZY DANYCH	Nie można zmienić właściciela bazy danych systemu master, model, tempdb, bazy danych zasób lub bazy danych, który jest używany jako baza danych dystrybucji.Główny zobowiązany musi być identyfikator logowania.Jeżeli główny zobowiązany jest identyfikator logowania systemu Windows bez odpowiadającego SQL Server identyfikator logowania, główny zobowiązany musi mieć uprawnienie do sterowania serwera i uprawnienia PRZEJMIJ na własność bazy danych.Jeżeli główny zobowiązany jest SQL Server identyfikator logowania, głównego zobowiązanego nie mapowany do certyfikat lub kluczasymetrycznego.Aliasy zależnych będzie mapowany na nowy właściciel bazy danych.DBO SID będzie aktualizowany w bieżącej bazie i w sys.databases.
OBIEKT	Nie można zmienić własność wyzwalaczy, ograniczenia, zasady, ustawienia domyślne, statystyki, obiekty systemowe, kolejek, widoki indeksowane lub tabele, widoki indeksowane.
SCHEMAT	Po przeniesieniu własności uprawnień do obiektów zawartych w schemacie, które nie mają wyraźne właścicieli zostaną usunięte.Nie można zmienić właściciela sys, dbo, lub information_schema.
TYP	Nie można zmienić własność tego typu, który należy do sys lub information_schema.
Umowy, typ wiadomości lub usługi	Nie można zmienić własność obiektów systemowych.
KLUCZ SYMETRYCZNY	Nie można zmienić własność globalnych kluczy tymczasowe.
CERTYFIKATÓW lub klucza asymetrycznego	Nie można transferować własność tych podmiotów do roli lub grupy.
PUNKT KOŃCOWY	Główny zobowiązany musi być identyfikator logowania.

Uprawnienia

Wymaga uprawnienia PRZEJMIJ na własność obiekt.Jeśli nowy właściciel nie jest użytkownik, który jest wykonywanie tej instrukcja, wymaga także albo 1) uprawnienia PERSONIFIKUJ na nowego właściciela, użytkownika lub logowania; lub 2) w przypadku nowego właściciela roli, członkostwo w roli lub ZMIEŃ uprawnienia roli; lub 3) Jeśli nowy właściciel jest rola aplikacji, ZMIEŃ uprawnienia rola aplikacji.

Przykłady

A.Transferowanie własności tabela

Poniższy przykład przeniesienie własności tabela Sprockets użytkownikowi MichikoOsada.W tabela znajduje się wewnątrz schematu Parts.

ALTER AUTHORIZATION ON OBJECT::Parts.Sprockets TO MichikoOsada;
GO

Kwerenda może również wyglądać następująco:

ALTER AUTHORIZATION ON Parts.Sprockets TO MichikoOsada;
GO

B.Transferowanie własności widoku do właściciela schematu

Poniższy przykład przeniesienie własności widoku ProductionView06 do właściciela schematu, który zawiera goWidok znajduje się wewnątrz schematu Production.

ALTER AUTHORIZATION ON OBJECT::Production.ProductionView06 TO SCHEMA OWNER;
GO

C.Transferowanie własności schematu do użytkownika

Poniższy przykład przeniesienie własności schematu SeattleProduction11 użytkownikowi SandraAlayo.

ALTER AUTHORIZATION ON SCHEMA::SeattleProduction11 TO SandraAlayo;
GO

D.Transferowanie własności punkt końcowy na logowanie do serwera SQL

Poniższy przykład przeniesienie własności punktu końcowego CantabSalesServer1 do JaePak.Ponieważ punkt końcowy jest serwer -poziom zabezpieczany, punkt końcowy mogą być transferowane tylko do serwera -poziom głównego.

ALTER AUTHORIZATION ON ENDPOINT::CantabSalesServer1 TO JaePak;
GO

Zobacz także

Odwołanie

OBJECTPROPERTY (Transact-SQL)

TYPEPROPERTY (Transact-SQL)

EVENTDATA (Transact-SQL)

Koncepcje

Oddzielanie schematu użytkownika