Gibt es eine „sind Sie sicher, dass“ für die Ausführung einer gespeicherten Prozedur? :)

Question

ich eine gespeicherte Prozedur haben, die eine Menge von Lösch tut. Hunderttausende von Datensätzen. Es ist nicht von der Anwendung sein würde runnable, aber immer noch, ich bin besorgt, dass einer meiner Kunden läuft es aus Versehen (i Probleme hatte zuvor wegen ihrer „Neugier“): D

Ja. gibt es Sicherungen und solche Sachen, aber ich dachte .... sie nicht zu erschrecken ... ist es eine Möglichkeit, um den Benutzer zu fragen: „Sind Sie sicher?“ vor der Ausführung? :) Dank

Answer 1

Ich denke, man einen Parameter haben könnte „Bestätigung“ genannt, die eine bestimmte Zeichenfolge erfordert (e, g, „Ich weiß, was ich tue“) übergeben werden, wenn es nicht gesetzt ist, oder falsch gesetzt wird, nur Rückkehr aus dem Verfahren ohne den Hauptcode ausgeführt wird. Nicht genau das, was Sie wollen, aber es ist eine Option.

zB - (ungetestet und wahrscheinlich schreckliche Syntax)

CREATE PROCEDURE dbo.mySproc (
@Confirmation Varchar(100)
) AS
BEGIN
    if(@Confirmation <> 'I know what I am doing')
    BEGIN
        return;
    END
    DELETE from table_name where condition
END

Answer 2

Kurz gesagt, nein.

Die Theorie besagt, dass jemand mit Berechtigungen der Lage zu finden und sein, eine gespeicherte Prozedur auszuführen, erlaubt sein soll. Es wäre besser, Berechtigungen zu beschränken, so dass diejenigen mit einem Überschuss Neugier nicht über die Berechtigung, um diese auszuführen.

Die andere, weniger sichere Option wäre ein vordefinierte Geheimnis zu verlangen, dass Bedürfnisse als Parameter übergeben werden - natürlich könnten sie Skript nur die gespeicherte Prozedur aus, das Geheimnis zu finden, obwohl ...

Natürlich würde der andere Punkt sein: Wenn es nicht aufrufbar ist, warum es enthält? Nach allem, wenn Sie Admin-Typ Aufgaben kommen zu tun, können Sie die Anweisungen haben als Datei Skript aus, dass Sie sicher auf Ihrem eigenen Rechner halten

Answer 3

verwenden, um einen mehrstufigen Säulen-Ansatz:

1) Steuer Sicherheit ausführen, wie:

GRANT EXECUTE ON [dbo].[yourProcedure] TO [userxyz]

2) verwenden, um ein wirklich beschreibend / beängstigend Prozedurnamen, wie

CREATE PROCEDURE Will_Delete_All_Your_Data ...

3) stellte einen großen Blickfang Kommentar am Anfang der gespeicherten Prozedur

--NOTE, will delete all of your data--
--NOTE, will delete all of your data--
--NOTE, will delete all of your data--
--NOTE, will delete all of your data--
--NOTE, will delete all of your data--

4) machen den Benutzer-Pass in einem verschleierten speziellen Zugangscode:

CREATE PROCEDURE Will_Delete_All_Your_Data
(
    @SpecialCode varchar(30)
)

IF @SpecialCode!=CHAR(83)+CHAR(112)+CHAR(101)+CHAR(99)+CHAR(105)+CHAR(97)+CHAR(108)+CHAR(67)+CHAR(111)+CHAR(100)+CHAR(101)
BEGIN
    RETURN 999
END
...

FYI, muss der spezielle Code sein 'SpecialCode' oder RETURN 999 Treffer.

Answer 4

Sie können einen @reallyReallyReallyDelete Parameter auf den sproc hinzufügen, die als Sicherheitsmaßnahme dienen wird. Wenn es Satz YesYesYes tatsächlich die Transaktion fest

Answer 5

Sie könnten ein wenig Eingang genannt @UserKnowsWhatTheyAreDoing verwenden und überprüfen, um zu sehen, ob es vor der Ausführung wahr ist. Wenn es falsch ist, eine freundliche Nachricht ausdrucken und anmutig aus dem Verfahren zurückkehrt

Answer 6

Das Verfahren kann ein Argument mit einem bestimmten Wert, wie 'Yes I know what I'm doing' erfordern. Oder es für eine Reihe aussehen kann ein eine spezielle Tabelle mit einer ähnlichen Bestätigung und einem aktuellen Zeitstempel.

Answer 7

Hier ist noch ein weiterer Ansatz, die ich denke, fit für den besonderen Fall ist, wenn eine Prozedur durch einen Benutzer aufgerufen werden soll, direkt und nicht aus einer Anwendung.

Ich muss sagen, schlägt es weniger Mühe für den Benutzer während mehr (vielleicht überproportional) für den Entwickler im Vergleich zu den meisten anderen Vorschläge. Sie entscheiden, ob es Ihnen passt.

Wie auch immer, hier geht.

Sie erstellen zunächst eine spezielle Tabelle, CriticalCalls, Anrufe zu kritischen Verfahren zu registrieren. Die Tabelle würde eine Struktur wie folgt aussehen:

SPID int,
ProcName sysname,
CallTime datetime

Im Grunde ist die Idee, dass eine kritische SP sollte zweimal aufgerufen werden: zuerst registriert er seinen Ruf und informiert den Benutzer den Anruf innerhalb eines bestimmten Zeitintervalls als Bestätigung ihrer Absicht zu wiederholen, und mit dem zweiten Anruf, wenn entsprechend gemacht, es geht tatsächlich mit seiner Aufgabe.

So ist der Ausgang Teil jeden kritischen Verfahrens würde diese Logik hat:

IF NOT EXISTS (
  SELECT *
  FROM CriticalCalls
  WHERE SPID = @@SPID AND ProcName = @ThisProcName
    AND GETDATE() - CallTime BETWEEN @LowerCallTimeLimit AND @UpperCallTimeLimit
    /* the actual test for the time interval might be somewhat different */
) BEGIN
  ...  /* upsert CriticalCalls with the current time stamp */
  PRINT 'To proceed, please call this procedure again within...';
  RETURN;
END;

DELETE FROM CriticalCalls WHERE SPID = @@SPID AND ProcName = @ThisProcName;

...  /* proceed with your critical task */

Eigentlich, denke ich, wäre es am besten ein spezielles SP zu verwenden (mit dem Namen CheckCriticalCalls unten) für alle Manipulationen mit CriticalCalls, inklusive aller notwendigen Modifikationen. CheckCriticalCalls würde den Namen des Verfahrens erhält eine Art Flag geprüft und Rückkehr zu zeigen, ob das angegebene Verfahren seinen realen Betrieb durchführen soll.

So ist es so aussehen eher könnte:

EXECUTE @result = CheckCriticalCalls 'ThisProcedureName';
IF @result = -1 BEGIN
  PRINT 'Call me again';
  RETURN;
END;

...  /* go on with the task */

Die Idee, die untere Grenze des Intervalls hinter Einstellung wird lediglich um den Benutzer zu verhindern, dass eine kritische Prozedur aufrufen zweimal automatisch, das heißt, indem zwei identische EXECUTE... Linien in einer Charge ausführt. Die obere Grenze ist, ist natürlich notwendig, um 1) sicherzustellen, dass der Benutzer seine jüngste Absicht bestätigt die kritische Operation durchzuführen; 2) verhindert die Ausführung, wenn die vorhandenen Datensatz in CriticalCalls tatsächlich dort aus einer vergangenen Sitzung mit demselben SPID gelassen wird.

Also, im Grunde ein Intervall von 1-2 Sekunden auf eine halbe Minute wäre ganz natürlich für mich zu sein scheinen. Sie könnten stattdessen verschiedene Figuren wählen.

Answer 8

Müssen Sie wirklich aus der DB löschen? Wenn ich den zusätzlichen Platz leisten kann, werde ich lege eine ‚Gelöscht‘ Flag in meinen Tabellen und eine letzte aktualisierte Spalte. Auf diese Weise, wenn ein Datensatz aus Versehen zumindest gelöscht Ich kann es in der Regel der Spur zu kommen und es ziemlich leicht wiederherstellen. Nur so ein Gedanke.