Das scheint eine wirklich alberne Frage zu sein, aber ich habe eine Suche gemacht und ich kann nichts darüber finden.
Ich habe eine DB-Verbindungszeichenfolge, die ich in meiner web.config erzeuge: -
%Vor%oder
%Vor%aber ich brauche diese Verbindung nur gelesen werden. Ich habe alle meine linq-Objekte mit nur auf ihren Eigenschaften definiert, und keine meiner (MVC) Repository-Klassen haben .SubmitChanges () -Methoden in ihnen, so bin ich 99% sicher, dass das System diese DB nicht aktualisieren kann, aber ich würde auch gerne meine DB-Verbindung auf RO setzen, wenn irgend möglich. Mir ist klar, dass dies idealerweise am SQL-Server-Ende geschehen sollte und der Benutzer sollte RO sein, aber das (aus verschiedenen Gründen, außerhalb meiner Kontrolle) kann nicht gemacht werden, also wollte ich meine Verbindung als App sperren darf nicht in die DB schreiben.
Gibt es einen "readonly" -Parameter, den ich auf die Verbindungszeichenfolge anwenden kann, um einen Fehler auszulösen oder die Daten zu verwerfen, wenn irgendwelche Aktualisierungen versucht wurden?
Nur zur Wiederholung (die erste Antwort, die ich hatte, als ich dies in einem anderen Forum fragte, war "Ändern Sie Ihre DB-Anmeldeinformationen") Ich kann die DB-Zugriffsberechtigungen in keiner Weise ändern, dies sind RW und alle Versuche, sie zu ändern (derzeit) stürzt die SQL Server DB ab. Das ist nicht mein Problem, und ich kann nicht versuchen, dieses Problem zu lösen, deshalb möchte ich versuchen, die DB-Verbindung RO so zu machen, wie es absolut positiv ist, jeden zu töten .... errr, ich meine absolut, positiv kann die DB-Daten nicht ändern.
Prost
MH
Was Sie unter Ihrer Kontrolle haben, ist Klassen für Zugangscode (L2S). Ich schlage vor, in einer partiellen Klasse die SubmitChanges für Ihren Datenkontext zu überschreiben, um nichts zu tun (oder sogar einen Fehler zu erzeugen!) (Oder alle Erweiterbarkeitsmethoden InsertObject, UpdateObject oder DeleteObject, die zu Ihrem Datenkontext gehören)
Nein, es gibt keinen Weg (den ich kenne). Leider wäre es für Sie die richtige Methode, die Berechtigungen des aktuellen Benutzers zu ändern oder einen neuen Benutzer mit nur ausgewählten Berechtigungen zu erstellen. Ich weiß, das ist nicht die Antwort, nach der Sie suchen, aber einen Sql-Server zu haben, der abstürzt, wenn Sie versuchen, Dinge zu ändern, scheint ein Problem zu sein, das wirklich einen Blick wert ist. Liegt es daran, dass Sie das Konto "sa" verwenden, um eine Verbindung herzustellen? In diesem Fall sollten Sie einen anderen Benutzer erstellen und dem neuen Benutzer die entsprechenden Berechtigungen erteilen.
Es hängt wirklich davon ab, welche Datenbank und welchen DB-Provider Sie verwenden. Einige erlauben nur Lesezugriff auf die Verbindungszeichenfolge, andere nicht.
Zum Beispiel:
SQL Server 2005 CE verfügt bei Verwendung des .NET Compact Framework-Datenanbieters für SQL Server Mobile über einen möglichen File Mode=Read Only; -Parameter. (Siehe connectionstrings.com ).
SQL Server 2008 tut dies nicht .
Sie können mehr Informationen zu connectionstrings.com abrufen.
Es gibt nichts, was Sie auf der Ebene der Verbindungszeichenfolge tun können, das Schreibvorgänge außer dem Ändern des Benutzers verhindert - was Sie bereits gesagt haben, können Sie nicht tun.
In diesem Fall müssen Sie nur das Äußerste in Ihrem Code tun, um Schreibvorgänge zu verhindern. das heißt:
Es gibt jedoch noch immer nichts, was einen Programmierer davon abhält, mitzukommen, Ihre Verbindungszeichenfolge zu entfernen und sie in ihre eigene Verbindung zu stecken, um Schreibvorgänge auszuführen.
Sie könnten daher die Verbindungszeichenfolge an eine andere Stelle verschieben, auf die nur interner Code zugreifen kann (es wird immer noch text-driven sein, verwenden Sie jedoch keine Code-Konstante!); Es hindert niemanden daran, es zu benutzen - aber es macht es viel schwieriger.
(hinzugefügt) Ich sollte erklären, warum es es nicht schützt.
Abgesehen davon, dass die Quelle der Verbindungszeichenfolge wahrscheinlich zugänglich ist, selbst durch den Schutz mit Verschlüsselungsbibliotheken usw., gibt es nichts, was mich daran hindern könnte, sich neben dem Vertrauensgrad an Ihren Code zu erinnern und ihn aufzurufen. Sie könnten sich dafür entscheiden, die ganze Verschleierungsroute zu gehen, um zu verhindern, dass ich Ihren Code dekonstruiere; Aber diese Paranoia ist sicher nicht in Ihrem Entwicklungshaus erforderlich?
Letztendlich aber, weil es "SEP" (jemand anderes Problem) ist, wie Sie es nennen, und Sie haben keine Kontrolle darüber - wenn jemand Sie fragt, warum, trotz Ihrer besten Bemühungen, kann ich nicht
Tags und Links asp.net-mvc asp.net