Dynamische SQL's mit Variablen

ach, jetzt glaub ich weiss worauf du hinaus willst.

du meinst, nicht ich soll das template entwickeln, sondern der entwickler soll sich über die funktion immer wieder selbst das template generieren lassen, wenn er ein neues skript entwickeln will und es anschließend mit leben füllen!?
 
Werbung:
Grundsätzlich eine tolle Idee. Nur befürchte ich, daran wird sich nicht jeder halten. Am Anfang generieren sie über die Funktion ihr Template. Und beim 2. Auftrag nehme sie sich ihr vorheriges (funktionierendes) Skript und passen es für den neuen Auftrag an.

Also mein Ziel wäre es eigentlich gewesen, 1x zu Beginn des Skriptes die Zielspalte zu definieren, so dass sie im Skriptverlauf dann immer von dort aus abgerufen und verwendet werden kann. Bzw. wird sie ja nur vom MERGE verwendet.
 
Damit hast du doch nichts gewonnen. Das kann doch genauso kopiert und nicht angepasst werden.
Ihr habt ein organisatorisches Problem: Keine Tests, keine Abnahmen, kein Zwei Augen Prinzip.
 
Da hast du wohl nicht unrecht mit. Deshalb ist es mir ja so wichtig, dass wir im Kopf des Skriptes die Spalte festlegen und es damit dann funktioniert. Damit ist die Fehlerquelle zwar nicht 100%ig eliminiert, aber ich glaube das Risiko, hier einmal einen Fehler zu machen, sinkt dadurch halt erheblich.

Gibt es denn eine realistische Möglichkeit, es so zu lösen, also den Spaltennamen irgendwie "dynamisch" anzusprechen (ohne EXECUTE IMMEDIATELY)?
 
Nein, der Spaltenname muss zum Zeitpunkt des Parsens bekannt sein, damit der Plan berechnet werden kann.
D.h. Du ersetzt ihn entweder vor der Ausführung (wie auch immer) oder verwendest dynamisches SQL mit EXECUTE IMMEDIATE
 
Werbung:
Ok, das ist mal eine klare Aussage. Auch wenn es nicht das ist was ich hören wollte. Dann werde ich das mal mit den Kollegen besprechen. Vielleicht findet die Idee mit der Template-Funktion ja doch anklang.

Vielen Dank für Eure Hilfe!
 
Zurück
Oben