none
Rimozione di un utente RRS feed

  • Domanda

  • Buona sera, dal Management Studio ho aggiunto un nuovo utente ad un DataBase esplodendo il ramo protezione/utenti.Facendo doppio click sul nuovo utente nella pagina generale nella lista ''schemi di proprietà dell'utente'' al momento della creazione dell'utente ho selezionato due o tre voci che non riesco più a deselezionare. Volendo eliminare l'utente ricevo la notifica che si è ferificato un errore. Aprendo il link dell'errore alla fine c'e' scritto :"L'entità di database è proprietaria di schema nel database e non puo essere eliminata .. errore 15138"

    Cosa devo fare per eliminare l'utente ?

    Grazie.


    mario formosa
    martedì 26 luglio 2011 17:20

Risposte

  • salve mario,

    l'errore e' descrittivo a sufficienza... ti e' quindi necessario trasferire la proprieta' dello schema ad altro utente valido, oppure trasferire tutti gli oggetti presenti nello schema relativo ad altri schemi, rimuovere tale schema e quindi procedere..

    puoi quindi, nel primo caso, proseguire similarmente a

    SET NOCOUNT ON;
    USE master;
    GO
    CREATE DATABASE testdb;
    GO
    CREATE LOGIN TestLogin WITH PASSWORD = 'TestLogin';
    GO
    USE testdb;
    GO
    CREATE USER TestUser FROM LOGIN TestLogin;
    GO
    PRINT 'l''operazione viene eseguita con successo..'
    DROP USER TestUser;
    GO
    CREATE USER TestUser FROM LOGIN TestLogin;
    GO
    CREATE SCHEMA TestUserSchema AUTHORIZATION TestUser;
    GO
    PRINT 'l''utente ha uno schema del quale e'' proprietario, l''operazione fallisce..'
    DROP USER TestUser;
    GO
    ALTER AUTHORIZATION ON SCHEMA::TestUserSchema TO dbo;
    GO
    PRINT 'l''operazione viene eseguita con successo..'
    DROP USER TestUser;
    GO
    USE master;
    GO
    DROP DATABASE testdb;
    DROP LOGIN TestLogin;

    che crea un database di test, crea una login, mappa uno nuovo user del db alla login, prova a distruggerlo sia nel caso di assenza di proprieta' (che avviene con successo) che in caso di presenza (creazione dello schema associato), dove fallisce... trasferisce quindi la proprieta' dello schema ad altro utente e quindi distrugge con successo l'utente.. seguito da apposito clean up..

    saluti


    http://www.asql.biz - DbaMgr2k - DbaMgr and further SQL Tools http://www.hotelsole.com/
    • Contrassegnato come risposta Mario Formosa mercoledì 27 luglio 2011 09:47
    martedì 26 luglio 2011 22:44
    Moderatore
  • salve Mario,

    i BOL indicano precisamente: " ... The new schema is owned by one of the following database-level principals: database user, database role, or application role. Objects created within a schema are owned by the owner of the schema, and have a NULL principal_id in sys.objects. Ownership of schema-contained objects can be transferred to any database-level principal, but the schema owner always retains CONTROL permission on objects within the schema. ..."

    l'implementazione degli oggetti-contenitore SCHEMA e' diventata funzionale con SQL Server 2005, dove si e' voluto (finalmente) perseguire lo standard di separazione della proprieta' degli oggetti da un utente particolare... precedentemente a SQL Server 2005, ogni oggetto doveva essere proprieta' di un utente/ruolo di database, cosa che poteva comportare seri problemi architetturali nel momento di ristrutturazione di una base dati magari dovuta al licenziamento di un utente... cio' ha quasi sempre comportato l'utilizzo dell'utente "dbo" come proprietario comune di tutti gli oggetti, cosi' da non provocare problemi successivamente... sono cosi' stati correttamente implementati gli schema, che costituiscono dei contenitori di oggetti, e malgrado gli stessi schema debbano essere proprieta' di un database principal, tale proprieta' puo' essere trasferita con facilita' senza compromettere codice utente, riferimenti e quant'altro, quindi senza "invalidare" la base dati stessa... interessante in tal senso e' la sinossi espressa presso http://msdn.microsoft.com/en-us/library/ms190387.aspx

    saluti


    http://www.asql.biz - DbaMgr2k - DbaMgr and further SQL Tools http://www.hotelsole.com/
    • Contrassegnato come risposta Mario Formosa giovedì 28 luglio 2011 11:10
    mercoledì 27 luglio 2011 22:43
    Moderatore

Tutte le risposte

  • salve mario,

    l'errore e' descrittivo a sufficienza... ti e' quindi necessario trasferire la proprieta' dello schema ad altro utente valido, oppure trasferire tutti gli oggetti presenti nello schema relativo ad altri schemi, rimuovere tale schema e quindi procedere..

    puoi quindi, nel primo caso, proseguire similarmente a

    SET NOCOUNT ON;
    USE master;
    GO
    CREATE DATABASE testdb;
    GO
    CREATE LOGIN TestLogin WITH PASSWORD = 'TestLogin';
    GO
    USE testdb;
    GO
    CREATE USER TestUser FROM LOGIN TestLogin;
    GO
    PRINT 'l''operazione viene eseguita con successo..'
    DROP USER TestUser;
    GO
    CREATE USER TestUser FROM LOGIN TestLogin;
    GO
    CREATE SCHEMA TestUserSchema AUTHORIZATION TestUser;
    GO
    PRINT 'l''utente ha uno schema del quale e'' proprietario, l''operazione fallisce..'
    DROP USER TestUser;
    GO
    ALTER AUTHORIZATION ON SCHEMA::TestUserSchema TO dbo;
    GO
    PRINT 'l''operazione viene eseguita con successo..'
    DROP USER TestUser;
    GO
    USE master;
    GO
    DROP DATABASE testdb;
    DROP LOGIN TestLogin;

    che crea un database di test, crea una login, mappa uno nuovo user del db alla login, prova a distruggerlo sia nel caso di assenza di proprieta' (che avviene con successo) che in caso di presenza (creazione dello schema associato), dove fallisce... trasferisce quindi la proprieta' dello schema ad altro utente e quindi distrugge con successo l'utente.. seguito da apposito clean up..

    saluti


    http://www.asql.biz - DbaMgr2k - DbaMgr and further SQL Tools http://www.hotelsole.com/
    • Contrassegnato come risposta Mario Formosa mercoledì 27 luglio 2011 09:47
    martedì 26 luglio 2011 22:44
    Moderatore
  • Grazie Andrea per l’aiuto. Chiedo scusa per il fatto di non aver precisato nel post di esordio, che le mie conoscenze di  MSSqlserver sono abbastanza limitate, e che gli  schemi di proprietà dell’utente che volevo eliminare, le avevo selezionate senza capire quello che stavo facendo. Cercavo di capire provando.

    Relativamente a quanto richiesto nel primo post, ho risolto, grazie al tuo aiuto, trasferendo gli schemi di proprietà ad altro utente, mediante Management Studio. Da ciò mi  sembra di poter dedurre che uno schema di proprietà (che non so cosa sia) è associabile univocamente ad un solo utente. O no ?

    Inoltre non capisco se la selezione di uno schema di proprietà può essere tradotta in :”l’utente x è esclusivo proprietario dello schema y”, o “l’utente x è dotato delle proprietà dello schema y”

    Grazie ancora.
    mario formosa
    mercoledì 27 luglio 2011 09:47
  • salve Mario,

    i BOL indicano precisamente: " ... The new schema is owned by one of the following database-level principals: database user, database role, or application role. Objects created within a schema are owned by the owner of the schema, and have a NULL principal_id in sys.objects. Ownership of schema-contained objects can be transferred to any database-level principal, but the schema owner always retains CONTROL permission on objects within the schema. ..."

    l'implementazione degli oggetti-contenitore SCHEMA e' diventata funzionale con SQL Server 2005, dove si e' voluto (finalmente) perseguire lo standard di separazione della proprieta' degli oggetti da un utente particolare... precedentemente a SQL Server 2005, ogni oggetto doveva essere proprieta' di un utente/ruolo di database, cosa che poteva comportare seri problemi architetturali nel momento di ristrutturazione di una base dati magari dovuta al licenziamento di un utente... cio' ha quasi sempre comportato l'utilizzo dell'utente "dbo" come proprietario comune di tutti gli oggetti, cosi' da non provocare problemi successivamente... sono cosi' stati correttamente implementati gli schema, che costituiscono dei contenitori di oggetti, e malgrado gli stessi schema debbano essere proprieta' di un database principal, tale proprieta' puo' essere trasferita con facilita' senza compromettere codice utente, riferimenti e quant'altro, quindi senza "invalidare" la base dati stessa... interessante in tal senso e' la sinossi espressa presso http://msdn.microsoft.com/en-us/library/ms190387.aspx

    saluti


    http://www.asql.biz - DbaMgr2k - DbaMgr and further SQL Tools http://www.hotelsole.com/
    • Contrassegnato come risposta Mario Formosa giovedì 28 luglio 2011 11:10
    mercoledì 27 luglio 2011 22:43
    Moderatore
  • Grazie veramente di cuore per la spiegazione. Adesso mi impegnerò nello studio del fantastico Microsoft Sqlserver.

    Grazie.


    mario formosa
    giovedì 28 luglio 2011 11:11