2010-06-09 7 views
5

wenn ich eine gespeicherte Prozedur haben sageneine Spalte und aktualisieren Sie es in derselben gespeicherten Prozedur in SQL Server 2008

CREATE PROCURE w AS 

ALTER TABLE t ADD x char(1) 

UPDATE t set x =1 

Auch wenn es lässt mich schaffen, dass die gespeicherte Prozedur (wenn ich es schaffen, wenn x vorhanden ist), Wenn es ausgeführt wird, liegt ein Fehler in der UPDATE-Anweisung vor, da die Spalte x nicht existiert.

Was ist der konventionelle Weg, damit umzugehen, muss es die ganze Zeit kommen? Ich kann es umgehen, indem ich das UPDATE in EXEC setze, gibt es einen anderen/besseren Weg?

Dank

+3

Warum in aller Welt ändern Sie das Tabellenschema in sSproc? –

+0

quelle horreur huh? Es ist ein Urteilsspruch, vielleicht ein schlechter. Die Tabelle, die ich ändere, ist eine, in die Rohdaten hochgeladen werden. Und es wird verschiedene Tische mit verschiedenen Schemen geben. In allen Fällen benötigen sie diese beiden Spalten, die nicht in der Quelle enthalten sind. Die Spalten sind "tatsächliche Steuer-ID" und "ist die Steuer-ID eine programmatisch erfundene". Also ist der Schritt im s proc eher eine Art der Kommunikation mit den Menschen mit dem s proc, dass "dies der Punkt ist, an dem es keine Rückkehr gibt, du musst die Taxid Nummer hier aufstellen, wenn du keine gültige bekommen hast" . – TortTupper

Antwort

2

Anstatt eine Spalte wie diese Zugabe und dann seinen Wert zu aktualisieren, Sie

CREATE PROCEDURE w AS 

ALTER TABLE t ADD x char(1) NOT NULL CONSTRAINT abc DEFAULT 1 
+0

Elegante Lösung! Aber funktionieren wird, denke ich, nur wenn neue Spalte nicht erlaubt NULL – abatishchev

+0

Danke, aber 1 ist nicht wirklich der Wert, den ich dort will, ich möchte die neue Spalte auf einen Wert von einer "FROM" -Klausel aktualisieren; Ich hatte gerade 1 in meinem Beispiel als Platzhalter, um etwas Einfaches zu zeigen, das den Fehler verursachte. – TortTupper

+0

als zuerst den Wert in Varible erhalten und dann hier wählen @@ Variable = 1 ALTER TABLE t ADD x char (1) NOT NULL CONSTRAINT abc DEFAULT @@ Variable kann für Sie arbeiten –

3

ALTER TABLE im Zusammenhang mit der ersten Transaktion und UPDATE im Rahmen eine Spalte mit einem Standardwert hinzufügen von 2:

CREATE PROCEDURE w 
AS 
    BEGIN TRAN 
     ALTER TABLE .. 
    COMMIT 

    BEGIN TRAN 
     UPDATE .. 
    COMMIT 
END 
+0

Sounds Attactive, aber ich kann es nicht funktionieren : CREATE PROCEDURE p AS TRAN ALTER TABLE t ADD x CHAR (1) COMMIT BEGIN TRAN UPDATE t Anfangen x = 1 COMMIT Wenn ich "END" benutze bekomme ich einen Syntaxfehler. Wenn ich die Prozedur erfolgreich erstelle, bekomme ich immer noch den gleichen Fehler, wenn "x" zur Laufzeit nicht existiert (und würde einen anderen Fehler bekommen, wenn es existiert) – TortTupper

+0

@TortTupper: Es scheint, dass dies eine Einschränkung von SQL Server ist. Wie wäre es mit einem Fehler auf MS.Connect? Ich würde es aufwerten. Meine Problemumgehung: Erstellen Sie 2 separate SPs und rufen Sie sie Turn-by-Turn auf. Oder erstellen Sie eine 3., die 1. und 2. ruft – abatishchev

+0

@TortTupper: Eine andere Idee, warum es passiert. SQL Server kann keinen SP für den Zugriff auf eine noch nicht existierende Spalte während der SP-Erstellung erstellen. Also vielleicht ist deine Aufgabe noch nicht möglich .. ( – abatishchev

-1

Ich denke, dass Sie eine GO-Anweisung direkt nach dem Erstellen hinzufügen sollten.

Sql-Server wird die create so, und dann wird Ihr Update funktioniert gut.

0

Das Problem, das auftritt, besteht darin, dass Ihr Update für die vorhandene Tabelle validiert wird, bevor es das Erstellen für Ihre Prozedur ausführt.

Wenn Sie dazu verpflichtet sind, müssen Sie lediglich sicherstellen, dass die Tabelle nicht existiert, wenn Sie die Prozedur erstellen/ändern, wodurch der Parser den Pfad zur verzögerten Namensauflösung aufgrund des nicht vorhandenen Pfades herunterfährt Objekte.

Nachdem die Prozedur erstellt wurde, können Sie Ihre Tabelle erstellen.

Ich gehe davon aus, dass Ihr Prozess die Tabelle bereits ablöst/erstellt oder dass Sie ein solches Verfahren sowieso nicht wirklich benötigen würden.