Unsere Datenschutzrichtlinie wird in Kürze aktualisiert. Bitte sehen Sie sich die Vorschau an.

SQL Server 2016: Triggers, Stored Procedures und Funktionen

Late Binding

Testen Sie unsere 2019 Kurse

10 Tage kostenlos!

Jetzt testen Alle Abonnements anzeigen
Late Binding erlaubt es gespeicherten Prozeduren, Objekte zu verwenden, die zum Erstellungszeitpunkt nicht existieren. Dies erlaubt u.a. auch die Verwendung temporärer Tabellen.
08:42

Transkript

Ein weiterer interessanter Punkt bei der Entwicklung mit Stored Proceduren ist das Late binding. Das heißt Objekte, auf die eine Stored Procedure zugreift, müssen erst dann existieren, wenn der Zugriff tatsächlich stattfindet. Das heißt, es kann sein, dass eine Stored Procedure in ihren Code auf Objekte zugreift, die nicht existieren, allerdings dieser Codepfad auch nicht ausgeführt wird, in dem Fall würde es zu keinem Fehler führen. Das offenbart, dass beim Anlegen einer Stored Procedure relativ wenig passiert, ich zeige Ihnen das gleich mal, aber es ermöglicht auf der anderen Seite auch die Verwendung von temporären Tabellen, von den ja auch nicht unbedingt klar ist, dass sie bei jedem Aufruf wirklich existieren und Sie haben also hier die Möglichkeit mit den temporären Tabellen zu arbeiten und entsprechende Ergebnisse zusammenzustellen, die sich zum Schluss dann zurückgeben oder irgendwie anders in irgendeiner Art und Weise verwenden an der Stelle. Das geht zum Beispiel bei Views oder bei Tabellenwert-Skalarfunktionen nicht, nur bei Stored Procedures haben Sie aufgrund des Late bindings genau diese Möglichkeit. In der Praxis sieht das Laid binding so aus, dass ich mir hier eine Datenbank anlegen kann. Dann kann ich hier eine Stored Procedure anlegen und die Soterd Procedure kann zum Beispiel auf eine Tabelle zugreifen, die es überhaupt gar nicht gibt. Das würde er an der Stelle in keiner Weise monieren, weder dass die Spalten wahrscheinlich sinnfrei sind, als auch die Tabelle schon gar nicht vorhanden ist. Er würde feststellen, wenn es beispielsweise einen Syntaxfehler gibt, den würde er sofort bemerken. Das heißt, das Statement hier mit dem verunglückten SELECT würde auf jeden Fall zu einem Fehler führen. Das Statement hier unten würde nur dann zu einem Fehler führen, wenn ich hier diese name2- Spalte einkommentieren würde, weil in dieser Tabelle keine Spalte mit diesem Namen existiert. Das heißt, wenn ich das laufen lasse, dann habe ich ohne Weiteres eine gültige Stored Procedure, gut die kann nicht ausgeführt werden, weil entsprechend natürlich nach wie vor diese Tabelle nicht vorhanden ist, aber erstmal für ein SQL-Server ist das in Ordnung. Das heißt, beim Anlegen eine Stored Procedure passiert relativ wenig. Erst wenn ich das ausführe, bekomme ich wirklich eine Fehlermeldung. Das heißt, wenn ich natürlich hierhin gehe und sage Refresh, ich möchte in die Stored Procedures und ich möchte genau die eine auch ausführen, dann bekomme ich natürlich die entsprechende Fehlermeldung, dass databases2 überhaupt gar nicht vorhanden ist. Das ist auch korrekt und das soll er auch machen an der Stelle. Hier aber zu Entwurfszeit merkt er es auf keinen Fall. Damit kann ich hingehen und Stored Procedures anlegen, die auf temporäre Tabellen zugreifen, wie diese hier, und kann erst vor der Ausführung die temporäre Tabelle erstellen und dann entsprechend auf die Daten in dieser temporären Tabelle zugreifen. Ich kann sogar hingehen, ich drop mal gezielt diese temporäre Tabelle und führe dann gleich mal in einem Rutsch diesen Block aus, der in wesentlichen der temporären Tabelle den Inhalt dieses Databases zuordnet, die Stored Procedure aufruft, dann die temporäre Tabelle wieder löscht, dann hingeht und der temporären Tabelle von [sys] [syslogins] den Inhalt verpasst und dann die Soterd Procedure nochmal aufruft. Das sieht dann so aus. Das heißt ein und dieselbe Stored Procedure hat unterschiedliche Rückgaben zurückgegeben, weil jeweils T1 anders aussah zu den beiden Ausführungszeitpunkten. Das ist entsprechend das Late binding. Das ist schön für den Aufrufer und auch schön für den Programmierer, weil man sehr flexible sein kann, allerdings für den SQL-Server kann es von dem Performance relativ suboptimal sein, weil für ihn ist es ja jedes Mal ein kleines Überraschungspaket, was denn tatsächlich zu Ausführung kommt, sei es zumal, weil ich hier eine temporäre Tabelle habe, von der ich nicht weiß, wie sie aussieht, wenn die Stored Procedure ausgeführt wird, zum anderen kann innerhalb eine Stored Procedure durch E-Verzweigungen durchaus Codepfade mal so, mal so abgelaufen werden und das kann der SQL-Server im Vorfeld kaum berücksichtigen. Das heißt, die Stored Procedure nimmt möglicherweise für solche Szenarien, was die Performance betrifft ein richtiger Killer, dafür aber extrem performant. Und in der Tat ist es so, dass Stored Procedures die schnellste Art sind, wirklich auf Daten zuzugreifen. Das heißt, wenn Sie nur Statements haben, die auf bestehende Tabellen zugreifen, ist das kein Problem, die kann einmal kompiliert werden, es gibt dann einen sprechenden Ausführungsplan für die Stored Procedure. Wenn ich aber temporäre Tabellen benutze, heißt, dass ich jedes Mal die Stored Procedure kurz vor Ausführung nochmal neu kompilieren muss und entsprechend dann entscheiden kann, erst wie er die Stored Procedure ausführt, weil das hier kann immer eine unterschiedliche Tabelle sein, deswegen funktioniert das, also schön für die Flexibilität, möglicherweise aber nicht ganz so toll für den SQL-Server, aber da muss man es dann an der Stelle schon relativ bunt treiben. Nichtsdestotrotz ein tolles Mittel. Eine andere Möglichkeit, die mir das Late binding im Bezug auf temporären Tabellen ermöglicht, ist es das Durchreichen von temporären Tabellen. Ich kann mir also die Datenbank wieder neu und frisch anlegen lassen und dann kann ich eine Stored Procedure definieren, die nichts anderes macht, als den Inhalt dieser temporären Tabelle auszugeben und ich kann ein zweite Stored Procedure bauen, die zwei Dinge tut, diese T1 temporäre Tabelle zu befüllen mit gewissen Inhalt und dann die zweite Stored Procedure aufzurufen. Das kann ich machen. Dann kann ich entsprechend die zweite Stored Procedure einmal aufrufen und was passiert ist, die temporäre Tabelle wird angelegt. Hier die Stored Procedure, die DumpTempTable, hat noch Zugriff auf diese temporäre Tabelle. Die existiert allerdings nur für den Lauf innerhalb der übergeordneten Stored Procedure, also der Stored Procedure TempTable. Ich rufe das mal auf, das funktioniert. Und ich fahre mir das zurück, während ich jetzt hier nicht mehr auf T1 zugreifen kann, das gibt ein Fehler an der Stelle. Interessant ist hier, ich kann eine temporäre Tabelle in einer Stored Procedure benutzen. Stored Procedures, die wiederum aufgerufen werden von dieser Stored Procedure, haben überhaupt kein Problem auf diese temporäre Tabelle zuzugreifen. Allerdings der Aufrufer der Stored Procedure, spricht der Aufrufer dieser Stored Procedure, hat kein Zugriff mehr auf die temporäre Tabelle. Das liegt daran, dass diese temporäre Tabelle nur innerhalb dieses Scopes läuft, das heißt, genau nur in diesem Block, und wenn der zu Ende ist, wird die temporäre Tabelle an der Stelle eliminiert und das ist ein anderes Verhalten, dass ich habe, als wenn ich jetzt hier wirklich auf Batchebene hingehe und eine temporäre Tabelle anlege. Die wird nämlich so lange bestehen bleiben, bis ich entsprechend die Verbindung eliminiere. Hier ist die temporäre Tabelle Scope-bezogen und Scope ist spätestens nach Ausführung, also quasi beim Ende, hier unten in dieser Stored Procedure zu Ende. Deshalb brauche ich in sehr vielen Fällen nicht dafür sorgen, dass die temporäre Tabelle auch eliminiert wird. Also ich könnte natürlich hingehen und zum Beispiel mir überlegen, dass es eine Idee wäre hier die temporäre Tabelle zu löschen, das könnte ich tun und hätte damit aber das gleiche Ergebnis im Wesentlichen, also ich würde mehr machen. Hier gibt es nach wie vor den Fehler. Ich müsste also um einen fehlerlosen Aufruf zu bekommen, das ausführen. Ich könnte das machen, aber ich hätte dann mehr Code in meiner Stored Procedure, als ich in der Tat brauche. Sie müssen temporäre Tabellen in Stored Proceduren nicht aufräumen, insofern sie in der Stored Procedure auch erzeugt wurden. Wenn sie von außen kommen, das heißt, vor dem Aufruf der Stored Procedure erzeugt wurden, können Sie, wenn Sie möchten, die temporäre Tabelle eliminieren. Allerdings kann es natürlich sein, dass, wenn ich vor dem Aufruf eine temporäre Tabelle erzeuge, dann die Procedure aufrufe, dass ich nach dem Aufruf möglicherweise immer noch auf die Tabelle zugreifen will und es kann sein, dass das nicht funktioniert und da gibt es eigentlich die Regel, dass man nur Elemente eliminiert, die man entsprechend auch selber angelegt hat.

SQL Server 2016: Triggers, Stored Procedures und Funktionen

Nutzen Sie in SQL Server Trigger, gespeicherte Prozeduren, Late Binding, Fehlerbehandlung sowie Scalar- und Tabellenwertfunktionen.

3 Std. 12 min (44 Videos)
Derzeit sind keine Feedbacks vorhanden...
 
Hersteller:
Software:
Exklusiv für Abo-Kunden
Erscheinungsdatum:08.08.2016

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!