Beim Testen war der Benutzer auf einer db, die ich benutzt habe, ein großer Jefe. In der Produktion hat er nur Execute.
Als ich anrief,
%Vor%Beim Testen hat es funktioniert. Ich versuche das gleiche in der Produktion, und ich bekomme das:
Die DELETE-Anweisung steht im Konflikt mit der REFERENCE-Einschränkung "FK__aspnet_Us__UserI__37703C52". Der Konflikt ist in der Datenbank aufgetreten "Testing", Tabelle "dbo.aspnet_UsersInRoles", Spalte "UserId".
Bei meinen Suchen (Suchen auf Google) stieß ich auf diesen Link wo der Kerl sagte,
Fehler: Die DELETE-Anweisung ist in Konflikt geraten mit der REFERENCE-Einschränkung "FK__aspnet_Me__UserI__15502E78". Das Konflikt trat in der Datenbank auf "YourDBName", Tabelle "dbo.aspnet_Membership", Spalte 'UserId'.
Ich habe eine Weile gebraucht, um eine Lösung zu finden dies über mehrere Standorte und Optionen als der Fehler und mögliche Lösungen waren eher irreführend. Stellt sich heraus, bei zumindest in meinem Fall war es ein Problem mit Berechtigungen für die Mitgliedschaft Datenbank. Der Benutzer, mit dem ich arbeite connect hatte Zugriff auf die Mitgliedschaftsdetails innerhalb der Datenbank selbst, aber als Teil der aspnet_Users_DeleteUser gespeichert Verfahren wählt es aus der sysobjects-Tabelle Die Mitgliedschaft Verbindung Benutzer offenbar nicht ausreichende Rechte haben, dies zu tun Wählen Sie dies aus, damit das Löschen insgesamt fehlschlägt.
Die Lösung für mich bestand darin, den Benutzer hinzuzufügen die aspnet_Membership_FullAccess-Rolle für die Mitgliederdatenbank.
Aber als ich das gemacht habe, hat es nicht funktioniert. Hat jemand Ideen, wie man damit umgehen soll?
Nach einer kleinen Inspektion fand ich das Problem in der aspnet_Users_DeleteUser gespeicherten Prozedur:
%Vor%Es gibt 3 andere ähnliche Zeilen für 3 andere Tabellen. Wenn der Benutzer, der den gespeicherten Prozess ausführt, keinen Zugriff auf vw_aspnet_MembershipUsers hat, tritt das Problem nicht auf, wenn er aus sysobjects auswählt. Ich bin neugierig zu wissen, warum diese ganze EXISTS-Anweisung notwendig ist.
Unabhängig davon, die folgende Diskussion, " Zugriff auf sysobjects, um Benutzer Tabellen ohne Zugriff auf die Benutzertabellen direkt in SQL Server Security ", hat die Antwort. Durch das Gewähren von "VIEW DEFINITION" für die fraglichen Ansichten werden die EXISTS-Anweisungen jetzt erfolgreich ausgeführt, und Sie müssen dem Benutzer in der Verbindungszeichenfolge der Anwendung keine unnötigen, unerwünschten oder übermäßigen Berechtigungen gewähren.
Ich hatte auch dieses Problem und es wurde durch fehlende Sichten verursacht. Um das zu korrigieren, habe ich einfach das Erstellungsskript aus einer anderen Datenbank verwendet und alle vw_aspnet_ * Ansichten neu erstellt.
OK, rate mal was? Ich lese das: Ссылка
Ok, wenige Minuten nach dem Senden meiner Post Ich habe die Lösung gefunden :) Es stellt sich heraus dass SELECT PERMISSION hinzugefügt werden musste für ASPNET-Benutzer an vw_aspnet_MembershipUsers-Ansicht.
Aber es ist immer noch ein Geheimnis, warum ich das nicht getan habe einen Fehler bezüglich des Mangels bekommen Genehmigung. EXIST-Anweisung war nur Falsch zurückgeben.
und gab dem Produktionsbenutzer SELECT Erlaubnis und voila! Es klappt! Danke Leute!
Ich glaube, dass Ihre Einschränkung "REFERENCE" tatsächlich ein Fremdschlüssel in der Datenbank ist, die zwischen der Tabelle "aspnet_Users" und der Tabelle "aspnet_UsersInRoles" vorhanden ist. Ich würde herausfinden, dass der Benutzer, den Sie versuchen, seine UserId in beiden Tabellen hat, und bevor Sie es aus der Tabelle Benutzer entfernen können, muss es auch aus der UsersInRoles-Tabelle entfernt werden.
Haben Sie Ссылка ausprobiert, um sicherzustellen, dass alle Rollen werden von diesem Benutzer entfernt? Sie können dies auch überprüfen, indem Sie die Zeilen dieser beiden Tabellen in der Datenbank überprüfen.
Wenn der Fehler (oder ein ähnlicher Fehler) nach dem Gewähren des ASP-Benutzers SELECT auf dem vw_aspnet_MembershipUsers weiterhin bestehen bleibt, möchten Sie möglicherweise SELECT für einige der anderen vw_aspnet _ ???? Ansichten auch. Vor allem "Profil" und "UsersInRoles". Andernfalls - aus bestimmten Gründen erhält der DeleteUser SP bei der Auswahl aus diesen Sichten ein leeres Ergebnis und verweigert das Löschen vorhandener Einträge aus diesen Sichten.
Vielleicht besser, um sicherzustellen, dass der Benutzer, der die Löschmitgliedschaft ausführt, die SQL-Rollen der ASP.NET-Mitgliedschaft korrigiert. In meinem Fall löschte ich einen Mitgliedschaftsbenutzer mit einigen Rollen und Profileigenschaften. Die Löschmethode ist fehlgeschlagen, aber nach dem Zuweisen der richtigen SQL-Rollen hat es funktioniert.
%Vor%Sie können auch [aspnet_Personalization_FullAccess] hinzufügen, wenn Sie diese Funktionalität verwenden.
Ich löste das, indem ich die Zeile in der Prozedur lösche, die nach der Ansicht sucht. Ich habe keine ASP-Mitgliedschaftsansichten und habe sie auch nirgends gebraucht, daher erscheint es ziemlich sinnlos, die Ansicht nur so zu erstellen, dass die Codezeile true zurückgeben kann - der proc verwendet diese Ansicht nicht. Wenn Sie mehr Features der Mitgliedschaftsobjekte verwenden, benötigen Sie möglicherweise die Ansicht für etwas anderes. In beiden Fällen scheint die Existenz der Ansicht zu prüfen, ob die aspnet_membership-Tabelle über eine Zeile verfügt, die gelöscht werden muss.
%Vor%Tags und Links asp.net asp.net-membership database-permissions