none
Rollen, Securables und Rechte einer Datenbank ermitteln RRS feed

  • Frage

  • Hallo,

    mir müssen für mehrere Tabellen auf mehreren Datenbanken einer SQL-Server 2008 R2 Instanz Tabellendefinitionen ändern.

    Da es sich um die Änderung von Feldgrößen handelt, geht das ja wohl nur durch Löschen und neu Anlegen der Tabellen.
    Nun gibt es in den Datenbanken diverse Rollen, die die Zugriffsberechtigungen steuern. Da durch das Löschen und neu Anlegen der Tabellen die Tabellennamen aus den Rollen fallen, benötige ich im Vorfeld die Möglichkeit, mir eine Übersicht über alle Rollen und deren Inhalte zu beschaffen.

    Diese Informationen müssten doch irgenwo in Datenbaktabellen gespeichert sein.
    Kann mir jemand einen Tipp geben?

    Gruß

    cheapy

    Freitag, 10. März 2017 11:57

Antworten

  • Ich wage zu hinterfragen, ob da nicht ein Design-Fehler vorliegt, wenn man Berechtigungen auf Tabellen-Ebene verwalten muss? Da ich Workarounds nur als Notpflaster vorschlagen würde, wage ich mal darauf hinzuweisen, dass man es möglicherweise anders angehen könnte.

    Kann man das wirklich nicht über die Schema-Berechtigungen regeln? Denn dann verliert man diese auch nicht - egal was man mit den Tabellen so anstellt.

    - Ich weiß, dass Thema wird nur stiefmütterlich behandelt, also nicht persönlich nehmen. Vielleicht hilft dieser ausführliche Artikel von mir da (und wenn nur für das nächste Design): Schema-Design für SQL Server: Empfehlungen für Schema-Design mit Sicherheit im Blick


    Andreas Wolter (Blog | Twitter)
    MCSM: Microsoft Certified Solutions Master Data Platform/SQL Server 2012
    MCM SQL Server 2008
    MVP Data Platform
    www.SarpedonQualityLab.com | www.andreas-wolter.com

    Freitag, 10. März 2017 15:07
  • Hallo Cheaptrick_la,

    Du musst für das Ändern von Datentypen nicht unbedingt eine neue Tabelle erstellen. Du hast die Möglichkeit, das mit Hilfe eines ALTER-Skripts machen (sofern keine Indexe und/oder Constraints, User-Datentypen) die Änderungen blockieren.

    USE demo_db; GO

    -- demo table CREATE TABLE dbo.Demo ( Id INT, C1 CHAR(100) ); GO

    -- ein paar Datensätze INSERT INTO dbo.Demo VALUES (1, 'Test'); GO

    -- Attribut geändert ALTER TABLE dbo.Demo ALTER COLUMN C1 CHAR(200) NOT NULL; GO


    Bei einem ALTER gehen die ursprünglichen Berechtigungen nicht verloren - bei einem DROP - CREATE sehrwohl!


    Uwe Ricken (Blog | Twitter)
    Microsoft Certiied Master - SQL Server 2008
    Microsoft Certified Solution Master - CHARTER Data Platform
    Microsoft Certified Solution Expert - Data Platform
    db Berater GmbH
    Microsoft SQL Server Blog (german only)

    Freitag, 10. März 2017 12:50

Alle Antworten

  • Hi,

    ich persönlich würde mir hierfür eine Kopie der Datenbank anlegen, die Änderungen im SSMS dort durchführen (dabei werden die Sicherheitseinstellungen, usw. korrekt behandelt) und dann bspw. per Red Gate SQL Compare den Abgleich durchführen lassen. Dabei werden dann auch alle Einstellungen, Berechtigungen, usw. mit übernommen.

    Falls Du es trotzdem manuell machen willst, hilft dir evtl. diese SP.

    EXEC sp_helprotect '<DeinTabellenname>'


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET
    http://www.asp-solutions.de/ - Consulting, Development
    http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community

    Freitag, 10. März 2017 12:13
    Moderator
  • Hallo Cheaptrick_la,

    Du musst für das Ändern von Datentypen nicht unbedingt eine neue Tabelle erstellen. Du hast die Möglichkeit, das mit Hilfe eines ALTER-Skripts machen (sofern keine Indexe und/oder Constraints, User-Datentypen) die Änderungen blockieren.

    USE demo_db; GO

    -- demo table CREATE TABLE dbo.Demo ( Id INT, C1 CHAR(100) ); GO

    -- ein paar Datensätze INSERT INTO dbo.Demo VALUES (1, 'Test'); GO

    -- Attribut geändert ALTER TABLE dbo.Demo ALTER COLUMN C1 CHAR(200) NOT NULL; GO


    Bei einem ALTER gehen die ursprünglichen Berechtigungen nicht verloren - bei einem DROP - CREATE sehrwohl!


    Uwe Ricken (Blog | Twitter)
    Microsoft Certiied Master - SQL Server 2008
    Microsoft Certified Solution Master - CHARTER Data Platform
    Microsoft Certified Solution Expert - Data Platform
    db Berater GmbH
    Microsoft SQL Server Blog (german only)

    Freitag, 10. März 2017 12:50
  • Hallo Cheapy,

    falls die beiden anderen Tipps nicht ausreichend helfen, kannst Du Dir natürlich auch die Berechtigungen anzeigen lassen und ich habe mir dafür auch einen Custom Report gebaut, wenn es mal schneller gehen soll.

    Berechtigungen im SQLServer 2005 anzeigen

    Artikel basiert zwar auf SQL Server 2005, funktioniert aber auch noch mit SQL Server 2016.


    Einen schönen Tag noch, Christoph -- Data Platform MVP - http://www.insidesql.org/blogs/cmu

    Freitag, 10. März 2017 14:08
    Beantworter
  • Ich wage zu hinterfragen, ob da nicht ein Design-Fehler vorliegt, wenn man Berechtigungen auf Tabellen-Ebene verwalten muss? Da ich Workarounds nur als Notpflaster vorschlagen würde, wage ich mal darauf hinzuweisen, dass man es möglicherweise anders angehen könnte.

    Kann man das wirklich nicht über die Schema-Berechtigungen regeln? Denn dann verliert man diese auch nicht - egal was man mit den Tabellen so anstellt.

    - Ich weiß, dass Thema wird nur stiefmütterlich behandelt, also nicht persönlich nehmen. Vielleicht hilft dieser ausführliche Artikel von mir da (und wenn nur für das nächste Design): Schema-Design für SQL Server: Empfehlungen für Schema-Design mit Sicherheit im Blick


    Andreas Wolter (Blog | Twitter)
    MCSM: Microsoft Certified Solutions Master Data Platform/SQL Server 2012
    MCM SQL Server 2008
    MVP Data Platform
    www.SarpedonQualityLab.com | www.andreas-wolter.com

    Freitag, 10. März 2017 15:07