{"id":55001491,"date":"2024-04-01T00:00:00","date_gmt":"2024-02-29T19:02:54","guid":{"rendered":"http:\/\/access-im-unternehmen.aix-dev.de\/aiu\/?p=1491"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-30T00:00:00","slug":"SQL_Server_Von_der_Abfrage_zur_Stored_Procedure","status":"publish","type":"post","link":"https:\/\/access-im-unternehmen.de\/SQL_Server_Von_der_Abfrage_zur_Stored_Procedure\/","title":{"rendered":"SQL Server: Von der Abfrage zur Stored Procedure"},"content":{"rendered":"

\"\"<\/p>\n

Die einfache Migration der Tabellen einer Datenbank von Access zum SQL Server ist meist schnell erledigt. Der SQL Server Migration Assistant (SSMA) leistet gute Arbeit und schnell landen alle Tabellen in der SQL Server-Datenbank – samt Erstellung entsprechender Tabellenverknüpfungen im Access-Frontend. Damit lässt sich erst einmal arbeiten, da die Verknüpfungen Lesen und Schreiben der Daten wie gewohnt zulassen. Früher oder später wird man jedoch auf Abfragen im Access-Frontend stoßen, die schlicht zu langsam sind. Und hier kann der SQL Server sein wahres Potential ausspielen: Zum Beispiel, indem wir dort eine Stored Procedure (Gespeicherte Abfrage) anlegen, welche die Abfrage für uns direkt auf dem SQL Server ausführt, was viel schneller gehen wird. Und genau das ist Thema dieses Beitrags: Wie bekommen wir eine mehr oder weniger komplizierte Abfrage als Stored Procedure zum SQL Server und rufen diese von der Access-Datenbank aus auf?<\/b><\/p>\n

Der SQL Server hat gegenüber einer Access-Datenbank eine besondere Stärke: Im Vergleich zu der Fileserver-Datenbank von Access kann der SQL Server Abfragen direkt auf dem Server ausführen und nur die Daten ausliefern, die tatsächlich benötigt werden.<\/p>\n

Bei Verwendung einer aufgeteilten Access-Datenbank werden immer alle Daten auf den anfragenden Rechner übertragen und dort ausgewertet. Was schneller geht, liegt auf der Hand, vor allem, je mehr Daten von der Abfrage betroffen sind.<\/p>\n

Deshalb schauen wir uns in diesem Beitrag im Detail an, wie wir eine reine Access-Abfrage zum SQL Server transferieren und dort eine Stored Procedure daraus erzeugen. <\/p>\n

Voraussetzungen<\/h2>\n

Damit wir in diesem Artikel reibungslos starten können, setzen wir voraus, dass die grundlegenden Migrationsarbeiten schon erledigt sind – also dass die Tabellen der Datenbank bereits auf dem SQL Server liegen und vom Frontend aus per ODBC-Tabellenverknüpfung gelesen und geschrieben werden können.<\/p>\n

Vor- und Nachteile von Stored Procedures<\/h2>\n

Kurz die wichtigsten Gründe für oder gegen gespeicherte Prozeduren: Gespeicherte Prozeduren können genau wie Access-Abfragen mit Parametern und allen anderen dort genutzten Funktionen verwendet werden und sie sind sehr schnell. Der Preis, den man bei Verwendung gespeicherter Prozeduren bezahlt, ist die fehlende Möglichkeit zum Ändern der Daten. Wenn wir eine gespeicherte Prozedur zum Lesen von Daten nutzen, um eine Access-Abfrage zu ersetzen, die auf Basis von per ODBC verknüpften Tabellen funktioniert, können wir die gelieferten Daten nicht direkt ändern beziehungsweise neue Datensätze anlegen oder vorhandene Datensätze löschen.<\/p>\n

Das ist aber in vielen Fällen auch nicht nötig – wir können mit gespeicherten Prozeduren erst einmal Daten etwa für Übersichten mit allen Datensätzen einer Tabelle holen, diese in einem Formular anzeigen und in einem weiteren Formular den zu bearbeitenden Datensatz erneut einlesen – diesmal auf Basis der per ODBC verknüpften Tabelle.<\/p>\n

Beispielabfrage aus der Praxis<\/h2>\n

Anlass für diesen Beitrag war eine Abfrage, mit der ich die Kunden ermittle, die in einem bestimmten Zeitraum ein oder mehrere bestimmte Produkte erworben haben und für die ich noch weitere Kriterien festlegen wollte.<\/p>\n

Die Abfrage habe ich bisher in Access auf die ODBC-Tabellenverknüpfungen angewendet. Die Abfrage lautet beispielsweise:<\/p>\n

SELECT DISTINCT KundeID, AnredeID, Nachname, Vorname, EMail, Land, Land_Rechnung FROM tblKunden WHERE KundeID IN (    SELECT tblAbonnements.KundeID     FROM tblAbonnements     WHERE tblAbonnements.ProduktID IN (146)     AND Startdatum >= #2024\/01\/01 00:00:00#     AND Startdatum <= #2024\/02\/01 00:00:00#) \r\nAND KundeID NOT IN (\r\n     SELECT tblAbonnements.KundeID \r\n     FROM tblAbonnements \r\n     WHERE tblAbonnements.ProduktID IN (96, 97)AND tblKunden.NLAbgemeldetAm IS NULL AND (    tblKunden.Land = ''Deutschland''     OR tblKunden.Land_Rechnung = ''Deutschland'')<\/pre>\n
Ich benötige also alle Kunden, denen über die Tabelle tblAbonnements <\/b>das Abonnement mit der Nummer 146 <\/b>zugeteilt wurde und deren Startdatum in einem bestimmten Datumsbereich liegt.<\/p>\n
Zusätzlich soll der Kunde nicht die Produkte 96 <\/b>und 97 <\/b>gebucht haben. Außerdem sollte der Kunde sich noch nicht vom Newsletter abgemeldet haben und entweder die Liefer- oder die Rechnungsadresse sollte in Deutschland liegen.<\/p>\n
Diese Abfrage wird zur Laufzeit per VBA zusammengestellt. Die notwendigen Parameter ermittle ich mit dem Formular aus Bild 1. Hier lasse ich mir zuerst alle Produkte anzeigen, die einen bestimmten Namen haben, übertrage dieses Produkt in die Liste oben rechts und füge gegebenenfalls noch Produkte in die Liste der nicht bestellten Produkte hinzu. Darunter gebe ich das Bestelldatum ein und das Land des Kunden. Außerdem kann ich noch angeben, ob Kunden ausgeschlossen werden sollen, die den Newsletter abgemeldet haben.<\/p>\n
\"Formular<\/p>\n
Bild 1: Formular zum Zusammenstellen der Abfrage<\/span><\/b><\/p>\n
Diese Parameter unter VBA zu einer funktionierenden Access-Abfrage zusammenzustellen ist eine Fleißarbeit, aber für jeden Programmierer zu bewerkstelligen. Der Code enthält eine Reihe von If…Then<\/b>-Bedingungen, die prüfen, ob eine bestimmte Option einen Wert enthält und fügt die entsprechenden Kriterien zur Abfrage hinzu.<\/p>\n
Der Weg zur Stored Procedure<\/h2>\n
Um diese Abfrage in eine gespeicherte Prozedur umzuwandeln und diese zu nutzen, sind einige Schritte nötig:<\/p>\n
    \n
  • Übertragen einer Version der Abfrage mit möglichst allen Kriterien in die Zwischenablage<\/li>\n
  • Einfügen des SQL-Codes in eine Stored Procedure<\/li>\n
  • Beheben der ersten auftretenden Syntaxfehler<\/li>\n
  • Ausprobieren, ob die Performance tatsächlich besser ist als in der Access-Abfrage<\/li>\n
  • Schrittweises Einführen von Parametern und Aufruf mit oder ohne die jeweiligen Parameter<\/li>\n
  • Wenn alle Parameter abgebildet sind, den Aufruf der gespeicherten Prozedur in der Access-Datenbank realisieren.<\/li>\n<\/ul>\n
    Anlegen der Stored Procedure<\/h2>\n
    Die gespeicherte Prozedur legen wir im SQL Server Management Studio über den Kontextmenü-Befehl Neu|Gespeicherte Prozedur… <\/b>des Eintrags Programmierbarkeit|Gespeicherte Prozeduren <\/b>der jeweiligen Datenbank (siehe Bild 2).<\/p>\n
    \"Hinzufügen<\/p>\n
    Bild 2: Hinzufügen einer neuen gespeicherten Prozedur<\/span><\/b><\/p>\n
    Damit erhalten wir eine Vorlage für eine neue gespeicherte Prozedur (siehe Bild 3, hier mit bereits entfernten Kommentaren). Was wir hier sehen, ist übrigens nicht die gespeicherte Prozedur selbst, sondern der Code, mit dem wir diese anlegen.<\/p>\n
    \"Vorlage<\/p>\n
    Bild 3: Vorlage für eine neue gespeicherte Prozedur<\/span><\/b><\/p>\n
    Die gespeicherte Prozedur selbst bekommen wir nie zu sehen – wir können uns später nur den Code ausgeben lassen, mit dem wir die gespeicherte Prozedur erneut anlegen oder ändern können.<\/p>\n
    Haben wir den Code zum Erstellen der gespeicherten Prozedur einmal ausgeführt und wollen diese nun ändern, müssen wir den Befehl CREATE PROCEDURE <\/b>durch ALTER PROCEDURE <\/b>ändern.<\/p>\n
    Doch eins nach dem anderen. Erst einmal ändern wir den Namen der gespeicherten Prozedur, indem wir  <\/b>durch unseren Namen ersetzen – zum Beispiel dbo.spGetCustomersWithSpecificProducts<\/b>.<\/p>\n
    Die Parameter löschen wir zuerst einmal, dann fügen wir statt der vorhandenen SELECT<\/b>-Anweisung unsere Abfrage aus der Access-Datenbank ein. Hier erhalten wir gleich markierte Stellen mit Fehlern (siehe Bild 4).<\/p>\n
    \"Fehler<\/p>\n
    Bild 4: Fehler im ersten Entwurf<\/span><\/b><\/p>\n
    Ich habe mich erst um den zweiten Fehler kümmern wollen, stellte aber dann fest, dass es sich nur um einen Folgefehler des ersten Fehlers handelte. Es empfiehlt sich also, Fehler in T-SQL von oben nach unten zu korrigieren, um solche Probleme zu verhindern.<\/p>\n
    Das Datum weist offensichtlich ein ungültiges Format auf. Wenn wir es in “2024-01-01“ <\/b>und “2024-02-01“ <\/b>ändern, verschwinden alle Fehler.<\/p>\n
    Erstmaliges Erstellen der gespeicherten Prozedur<\/h2>\n
    Nun erstellen wir die Prozedur durch Betätigen der Taste F5 <\/b>oder mit dem Menübefehl Abfrage|Ausführen<\/b>.<\/p>\n
    Dies liefert die Meldung, dass die Befehle erfolgreich ausgeführt wurden und nach einer Aktualisierung des Punktes Gespeicherte Prozeduren <\/b>im Objekt-Explorer finden wir die neue gespeicherte Prozedur dort vor.<\/p>\n
    Ausführen der gespeicherten Prozedur<\/h2>\n
    Um die gespeicherte Prozedur auszuführen, können wir ein neues Abfragefenster öffnen oder wir geben den Aufruf der Abfrage einfach in das bestehende Abfragefenster ein, in dem wir die gespeicherte Prozedur erstellt haben. Der Aufruf enthält den Befehl EXEC <\/b>und den Namen der auszuführenden gespeicherten Prozedur:<\/p>\n
    EXEC spGetCustomersWithSpecificProducts<\/pre>\n
    Wenn wir diesen Aufruf im gleichen Abfragefenster wir die CREATE PROCEDURE <\/b>anlegen, müssen wir diesen markieren und dann die Taste F5 <\/b>betätigen. Wenn wir zuvor nicht markieren, werden alle Befehle im Abfragefenster ausgeführt, also auch die CREATE<\/b>-Methode. Dies führt zu einem Fehler, weil wir die gespeicherte Prozedur bereits erstellt haben.<\/p>\n
    Führen wir die gespeicherte Prozedur jedoch separat aus, erhalten wir die gewünschten Datensätze (siehe Bild 5).<\/p>\n
    \"Abfrageergebnis\"<\/p>\n
    Bild 5: Abfrageergebnis<\/span><\/b><\/p>\n
    Anpassen der gespeicherten Prozedur<\/h2>\n
    Wenn die die gespeicherte Prozedur nun anpassen wollen, können wir direkt in dem Abfragefenster bleiben, in dem wir auch den CREATE PROCEDURE<\/b>-Befehl aufgerufen haben. Diesen ersetzen wir einfach durch den ALTER PROCEDURE<\/b>-Befehl. Damit ändern wir die bestehende gespeicherte Prozedur wie in der Anweisung angegeben.<\/p>\n
    Wenn wir nach dem Ändern immer gleich testen wollen, wie das aktuelle Ergebnis aussieht, können wir die beiden Anweisungen auch direkt untereinander platzieren. Wir erstellen dann zuerst die neue Version der Abfrage und führen diese dann direkt aus.<\/p>\n
    Tipp: IntelliSense-Cache aktualisieren<\/h2>\n
    Manchmal markiert der SQL Server den Namen einer bereits angelegten gespeicherten Prozedur oder von anderen Elementen. Dann ist möglicherweise der IntelliSense-Cache noch nicht aktualisiert. Das können wir auf zwei Arten nachholen:<\/p>\n
      \n
    • Tastenkombination Strg + Umschalt + R <\/b>drücken<\/li>\n
    • Menübefehl Bearbeiten|IntelliSense|Lokalen Cache aktualisieren <\/b>betätigen<\/li>\n<\/ul>\n
      Abfrage von Access aus ausführen<\/h2>\n
      Um die Abfrage in der jetzigen Form auszuführen, also ohne Parameter, führen wir die folgenden Schritte aus:<\/p>\n
        \n
      • Erstellen einer neuen Abfrage in der Entwurfsansicht<\/li>\n
      • Betätigen des Ribbonbefehls Abfrageentwurf|Abfragetyp|Pass-Through<\/b><\/li>\n
      • Einfügen des Aufrufs der Abfrage, also EXEC dbo.spGetCustomersWithSpecificProducts<\/b><\/li>\n
      • Eintragen der Verbindungszeichenfolge für die Eigenschaft ODBC-Verbindung.<\/li>\n<\/ul>\n
        Die Verbindungszeichenfolge kann in der Regel einer der per ODBC eingebundenen Tabellen entnommen werden – man braucht nur hinten den Parameter TABLE <\/b>zu entfernen (siehe Bild 6). In unserem Fall lautet die Verbindungszeichenfolge mit dem allgemeinen SQL Server-Treiber so:<\/p>\n
        \"Abfrageentwurf<\/p>\n
        Bild 6: Abfrageentwurf für den Zugriff auf eine gespeicherte Prozedur<\/span><\/b><\/p>\n
        ODBC;DRIVER=SQL Server;SERVER=amvdesktop2019;Trusted_Connection=Yes;DATABASE=Kundenverwaltung<\/pre>\n
        Wechseln wir nun in die Datenblattansicht der Abfrage, finden wir die gewünschten Datensätze in Millisekunden wie in Bild 7 vor.<\/p>\n
        \"Ergebnis<\/p>\n
        Bild 7: Ergebnis in Access in der Datenblattansicht der Abfrage<\/span><\/b><\/p>\n
        Parameter hinzufügen<\/h2>\n
        Damit kommen wir zum nächsten Schritt. Bisher liefert die Abfrage die Daten für die Parameter beziehungsweise Kriterien, die wir der Beispielabfrage entnommen haben. Wir wollen die Parameter aber von Access aus ermitteln und an die gespeicherte Prozedur übermitteln, damit diese auf dem SQL Server ausgewertet werden können.<\/p>\n
        Dazu ersetzen wir zuerst die Vergleichswerte durch entsprechende Parameter. Dabei können wir uns Schritt für Schritt durch die Abfrage arbeiten. Als Erstes wollen wir die Produkt-ID in dieser Zeile durch einen Parameter ersetzen:<\/p>\n
        WHERE tblAbonnements.ProduktID IN (146)<\/pre>\n
        Hier stellt sich gleich die Frage, ob wir einen Zahlenwert oder eine Zeichenkette übergeben. Immerhin ermitteln wir die zu untersuchenden Produkt-IDs in der aufrufenden Access-Anwendung und fügen diese zu einer Komma-separierten Liste zusammen – statt 146 <\/b>könnte hier also auch 146, 147, 148 <\/b>stehen. Der Einfachheit halber wollen wir hier mit einer Zeichenkette arbeiten. Dazu fügen wir der Abfrage einen Parameter namens @Produkte <\/b>mit dem Datentyp VARCHAR(255) <\/b>hinzu. Außerdem fügen wir diesen Parameter in die Klammern hinter dem IN<\/b>-Schlüsselwort ein:<\/p>\n
        ALTER PROCEDURE spGetCustomersWithSpecificProducts(\r\n   @Produkte VARCHAR(255)\r\n)\r\nAS\r\nBEGIN\r\n    SET NOCOUNT ON;\r\n    SELECT DISTINCT KundeID, AnredeID, Nachname,            Vorname, EMail, Land, Land_Rechnung \r\n    FROM tblKunden \r\n    WHERE KundeID IN (\r\n        SELECT tblAbonnements.KundeID \r\n        FROM tblAbonnements \r\n        WHERE tblAbonnements.ProduktID                  IN (@Produkte)<\/pre>\n
        Dies funktioniert nun mit folgendem Aufruf:<\/p>\n
        EXEC dbo.spGetCustomersWithSpecificProducts \"146\"<\/pre>\n
        Dann versuchen wir es mit dem folgenden Wert für den Parameter:<\/p>\n
        EXEC dbo.spGetCustomersWithSpecificProducts \"146, 147\"<\/pre>\n
        Das funktioniert nicht und wir erhalten die folgende Fehlermeldung:<\/p>\n
        Nachricht 245, Stufe 16, Status 1, Prozedur dbo.spGetCustomersWithSpecificProducts, Zeile 7 [Batchstartzeile 24]\r\nFehler beim Konvertieren des varchar-Werts \"146, 147\" in den int-Datentyp.<\/pre>\n
        Der SQL Server versucht, die Zeichenfolge 146, 147 <\/b>in den Datentyp des Feldes umzuwandeln, was hier nicht funktioniert. Wir müssen also schon an dieser Stelle zu einer Technik greifen, die sich dynamisches SQL nennt. Das ist nichts anderes, als wenn wir einen SQL-Ausdruck in VBA zusammensetzen – nur, dass dies im SQL Server geschieht. Für unseren Anwendungsfall haben wir nun die Änderungen wie in Listing 1 vorgenommen. Hier sehen wir, dass wir eine Variable namens @SQL <\/b>mit dem Datentyp NVARCHAR(MAX) <\/b>angelegt haben. Diese nimmt unseren SQL-Ausdruck auf, wobei wir hier den Inhalt von @Produkte <\/b>in die Zeichenkette integrieren. Am Ende rufen wir die eingebaute gespeicherte Prozedur sp_executesql <\/b>auf und übergeben dieser die SQL-Abfrage aus @SQL<\/b>.<\/p>\n
        ALTER PROCEDURE spGetCustomersWithSpecificProducts(\r\n   @Produkte VARCHAR(255)\r\n)\r\nAS\r\nBEGIN\r\n    SET NOCOUNT ON;\r\n    DECLARE @SQL NVARCHAR(MAX);\r\n    SET @SQL = N''SELECT DISTINCT KundeID, AnredeID, Nachname, Vorname, EMail, Land, Land_Rechnung \r\n    FROM tblKunden \r\n    WHERE KundeID IN (\r\n        SELECT tblAbonnements.KundeID \r\n        FROM tblAbonnements \r\n        WHERE tblAbonnements.ProduktID IN ('' + @Produkte + '') \r\n        AND Startdatum >= ''''2024-01-01'''' \r\n        AND Startdatum <= ''''2024-02-01''''\r\n        ) \r\n    AND KundeID NOT IN (\r\n        SELECT tblAbonnements.KundeID \r\n        FROM tblAbonnements \r\n        WHERE tblAbonnements.ProduktID IN (96, 97)\r\n        )\r\n    AND (Land = ''''Deutschland'''' \r\n        OR Land_Rechnung = ''''Deutschland'''')''\r\n    EXEC sp_executesql @SQL;\r\nEND\r\nGO\r\nEXEC dbo.spGetCustomersWithSpecificProducts \"146, 147\"<\/pre>\n
        Listing 1: Gespeicherte Prozedur mit dynamischem SQL<\/span><\/b><\/p>\n
        Das Ergebnis ist das gleiche wie zuvor – nur dass wir jetzt auch Ausdrücke wie 146, 147, 148 <\/b>für den Parameter @Kunde <\/b>übergeben können.<\/p>\n
        Auf die gleiche Weise fügen wir nun den Parameter hinzu, mit dem wir Kunden ausschließen wollen, die ein oder mehrere andere Produkte gekauft haben:<\/p>\n
        ALTER PROCEDURE spGetCustomersWithSpecificProducts(\r\n   @Produkte VARCHAR(255),\r\n   @NichtProdukte VARCHAR(255)\r\n)\r\n...\r\n     WHERE tblAbonnements.ProduktID IN ('' + @NichtProdukte + '')\r\n...<\/pre>\n
        Der Aufruf lautet nun beispielsweise wie folgt und liefert alle Kunden, welche die Produkte 146 oder 147 gekauft haben, aber nicht 1, 2, 3, 4, 5 oder 6:<\/p>\n
        EXEC dbo.spGetCustomersWithSpecificProducts \"146, 147\", \"1, 2, 3, 4, 5, 6\"<\/pre>\n
        Datum und Land als Parameter<\/h2>\n
        Wenn wir wie hier mit dynamischem SQL arbeiten, können wir auch das Datum und das Land direkt als Zeichenkette übergeben. Dazu definieren wir die entsprechenden Variablen und fügen diese analog zu den vorherigen Parametern in die Abfrage ein:<\/p>\n
        ALTER PROCEDURE spGetCustomersWithSpecificProducts(\r\n   ...\r\n   @DatumVon VARCHAR(50),\r\n   @DatumBis VARCHAR(50),\r\n   @Land VARCHAR(50)\r\n)\r\n...\r\n        AND Startdatum >= '''''' + @DatumVon + '''''' \r\n        AND Startdatum <= '''''' + @DatumBis + ''''''\r\n...\r\n    AND (Land = '''''' + @Land + '''''' \r\n        OR Land_Rechnung = '''''' + @Land + '''''')''<\/pre>\n
        Der Aufruf lautet dann:<\/p>\n
        EXEC dbo.spGetCustomersWithSpecificProducts \"146, 147\", \"1, 2, 3, 4, 5, 6\", \"2024-01-01\", \"2024-02-01\", \"Deutschland\"<\/pre>\n
        Parameter weglassen<\/h2>\n
        Nun wollen wir nicht immer alle Parameter nutzen. Wenn ein Parameter nicht vorhanden ist, müssen wir dementsprechend auch einen Teil der Abfrage weglassen. Die dazu notwendigen Änderungen haben wir in Listing 2 abgebildet.<\/p>\n
        ALTER PROCEDURE [dbo].[spGetCustomersWithSpecificProducts](\r\n   @Produkte VARCHAR(255) = NULL,\r\n   @NichtProdukte VARCHAR(255) = NULL,\r\n   @DatumVon VARCHAR(50) = NULL,\r\n   @DatumBis VARCHAR(50) = NULL,\r\n   @Land VARCHAR(50) = NULL\r\n)\r\nAS\r\nBEGIN\r\n    SET NOCOUNT ON;\r\n    DECLARE @SQL NVARCHAR(MAX);\r\n    DECLARE @WHERE NVARCHAR(MAX);\r\n    SET @SQL = N''SELECT DISTINCT KundeID, AnredeID, Nachname, Vorname, EMail, Land, Land_Rechnung \r\n    FROM tblKunden \r\n    WHERE KundeID IN (\r\n        SELECT tblAbonnements.KundeID \r\n        FROM tblAbonnements''\r\n    If @Produkte IS NOT NULL\r\n        SET @WHERE = '' AND tblAbonnements.ProduktID IN ('' + @Produkte + '')'';\r\n    IF @DatumVon IS NOT NULL\r\n        SET @WHERE = @WHERE + '' AND Startdatum >= '''''' + @DatumVon + '''''''';\r\n    IF @DatumBis IS NOT NULL \r\n        SET @WHERE = @WHERE + '' AND Startdatum <= '''''' + @DatumBis + '''''''';\r\n    IF @WHERE IS NOT NULL\r\n    BEGIN\r\n        SET @WHERE = SUBSTRING(@WHERE, 5, LEN(@WHERE));\r\n        SET @SQL = @SQL + '' WHERE '' + @WHERE;\r\n    END;\r\n    SET @SQL = @SQL + '')''\r\n    IF @NichtProdukte IS NOT NULL \r\n    BEGIN\r\n        SET @SQL = @SQL + ''AND KundeID NOT IN (\r\n        SELECT tblAbonnements.KundeID \r\n        FROM tblAbonnements \r\n        WHERE tblAbonnements.ProduktID IN ('' + @NichtProdukte + '')\r\n        )'';\r\n    END;\r\n    IF @Land IS NOT NULL \r\n    BEGIN\r\n        SET @SQL = @SQL + ''AND (Land = '''''' + @Land + '''''' \r\n        OR Land_Rechnung = '''''' + @Land + '''''')'';\r\n    END;\r\n    EXEC sp_executesql @SQL;\r\nEND\r\nGO<\/pre>\n
        Listing 2: Gespeicherte Prozedur mit optionalen Parametern<\/span><\/b><\/p>\n
        Die erste wichtige Änderung ist, dass wir für alle optionalen Parameter einen Standardwert angegeben haben – in diesem Fall lautet dieser jeweils NULL<\/b>:<\/p>\n
        ALTER PROCEDURE [dbo].[spGetCustomersWithSpecificProducts](\r\n   @Produkte VARCHAR(255) = NULL,\r\n   @NichtProdukte VARCHAR(255) = NULL,\r\n   @DatumVon VARCHAR(50) = NULL,\r\n   @DatumBis VARCHAR(50) = NULL,\r\n   @Land VARCHAR(50) = NULL\r\n)<\/pre>\n
        Auf diese Weise können wir im Verlauf prüfen, ob ein Parameter den Wert NULL <\/b>hat und abhängig davon ein bestimmtes Kriterium zur Abfrage hinzufügen oder auch nicht.<\/p>\n
        Wir wollen in diese Abfrage Kunden ermitteln, die bestimmte Abonnements haben oder auch nicht haben oder die in bestimmten Datumsbereichen liegen.<\/p>\n
        Die Basisabfrage sieht also so aus:<\/p>\n
        SELECT DISTINCT KundeID, AnredeID, Nachname, Vorname, EMail, Land, Land_Rechnung \r\nFROM tblKunden \r\nWHERE KundeID IN (\r\n     SELECT tblAbonnements.KundeID \r\n     FROM tblAbonnements\r\n     ... weitere Kriterien ...\r\n)<\/pre>\n
        Wenn einer der Parameter @Produkte<\/b>, @NichtProdukte<\/b>, @DatumVon <\/b>oder @DatumBis <\/b>angegeben wurde, soll an der Stelle, wo jetzt … weitere Kriterien … <\/b>steht, eine WHERE<\/b>-Bedingung eingebaut werden.<\/p>\n
        Diese bauen wir in den folgenden Zeilen zusammen. Als Erstes prüfen wir, ob @Produkte <\/b>einen Wert hat. Ist das der Fall, fügen wir einer Variablen namens @WHERE <\/b>beispielsweise die folgende Zeichenkette hinzu (angenommen, wir haben 1,2,3,4,5,6 <\/b>für @Produkte <\/b>übergeben):<\/p>\n
        AND tblAbonnements.ProduktID IN (1,2,3,4,5,6)<\/pre>\n
        Dann prüfen wir, ob ein Wert mit dem Parameter @DatumVon<\/b> übergeben wurde. Ist das der Fall, fügen wir an @WHERE <\/b>beispielsweise den folgenden Ausdruck an:<\/p>\n
        AND Startdatum >= ''2024-01-01''<\/pre>\n
        Das Gleiche erledigen wir für den Parameter @DatumBis. Hier lautet der Ausdruck, den wir mit den folgenden Anweisungen anlegen, wie folgt:<\/p>\n
        AND Startdatum <= ''2024-12-31''<\/pre>\n
        Nun hat @WHERE <\/b>entweder einen Wert, der sich aus einem oder mehreren der oben genannten Ausdrücke zusammensetzt, oder @WHERE <\/b>ist NULL<\/b>. Wenn @WHERE <\/b>nicht NULL <\/b>ist, beginnt der enthaltene Ausdruck mit dem Schlüsselwort AND <\/b>(mit führendem Leerzeichen). Das prüfen wir in der folgenden IF<\/b>-Bedingung, wo wir den Ausdruck @WHERE IS NOT NULL <\/b>untersuchen.<\/p>\n
        Ist @WHERE <\/b>nicht NULL<\/b>, entfernen wir die ersten fünf Zeichen aus dem enthaltenen Text. Anschließend fügen wir das Schlüsselwort WHERE <\/b>vorn ein. Wenn wir alle zuvor angegebenen Parameter genutzt haben, sieht der Inhalt von @WHERE <\/b>nun so aus:<\/p>\n
        WHERE tblAbonnements.ProduktID IN (1,2,3,4,5,6) AND Startdatum >= ''2024-01-01'' AND Startdatum <= ''2024-12-31''<\/pre>\n
        Diesen fügen wir nun mit der eigentlichen Abfrage wie folgt zusammen, indem wir @WHERE <\/b>an @SQL <\/b>anhängen und noch eine schließende Klammer anfügen:<\/p>\n
        SELECT DISTINCT KundeID, AnredeID, Nachname, Vorname, EMail, Land, Land_Rechnung    \r\nFROM tblKunden    \r\nWHERE KundeID IN (    \r\n     SELECT tblAbonnements.KundeID     \r\n     FROM tblAbonnements \r\n     WHERE tblAbonnements.ProduktID IN (1,2,3,4,5,6) \r\n     AND Startdatum >= ''2024-01-02'' \r\n     AND Startdatum <= ''2024-12-31'')<\/pre>\n
        Nun fehlt noch der Teil, der Kunden mit bestimmten Abonnements ausschließen soll. Hier prüfen wir einfach, ob @NichtProdukte <\/b>nicht den Wert NULL <\/b>hat.<\/p>\n
        In diesem Fall fügen wir, wenn wir beispielsweise den Ausdruck 10,12 <\/b>für @NichtProdukte <\/b>übergeben haben, den folgenden Teil zu @SQL <\/b>hinzu:<\/p>\n
        AND KundeID NOT IN (\r\n     SELECT tblAbonnements.KundeID \r\n     FROM tblAbonnements \r\n     WHERE tblAbonnements.ProduktID IN (10,12)<\/pre>\n
        Schließlich fehlt noch der Parameter @Land. Diesen berücksichtigen wir beispielsweise für den Wert Deutschland <\/b>wie folgt:<\/p>\n
        AND (Land = ''Deutschland'' OR Land_Rechnung = ''Deutschland'')''<\/pre>\n
        Schließlich führen wir den Inhalt von @SQL <\/b>mit der EXEC<\/b>-Methode aus:<\/p>\n
        EXEC sp_executesql @SQL;<\/pre>\n
        Aufruf von gespeicherten Prozeduren mit optionalen Parametern<\/h2>\n
        Damit können wir nun einen oder mehrere Parameter weglassen. Wenn wir die gespeicherte Prozedur mit der EXEC<\/b>-Anweisung aufrufen und einen oder mehrere Parameter weglassen wollen, haben wir verschiedene Möglichkeiten.<\/p>\n
        Die sicherste ist, alle Parameter, die übergeben werden sollen, als benannte Parameter anzugeben, also beispielsweise so:<\/p>\n
        EXEC dbo.spGetCustomersWithSpecificProducts @Produkte=\"1,2,3,4,5,6\", @Land=''DEUTSCHLAND''<\/pre>\n
        Auf diese Weise stellen wir sicher, dass wir keinen Fehler erhalten, auch wenn die gespeicherte Prozedur zwischenzeitlich um weitere Parameter ergänzt wird. Die zweite Variante gibt für alle nicht verwendeten Parameter den Wert NULL <\/b>als Parameter an. Für das vorherige Beispiel sähe das wie folgt aus:<\/p>\n
        EXEC dbo.spGetCustomersWithSpecificProducts \"1,2,3,4,5,6\", NULL, NULL, NULL, ''DEUTSCHLAND''<\/pre>\n
        Es kann auch sein, dass wir am Ende einen oder mehrere Parameter weglassen wollen.<\/p>\n
        In diesem Fall brauchen wir den Wert NULL <\/b>nicht explizit anzugeben:<\/p>\n
        EXEC dbo.spGetCustomersWithSpecificProducts \"1,2,3,4,5,6\"<\/pre>\n
        Wir können jedoch nicht, wie es beispielsweise beim Aufrufen von Funktionen oder Prozeduren unter VBA möglich ist einfach einen Parameterwert zwischen zwei Kommata weglassen. Der folgende Ausdruck würde also nicht funktionieren:<\/p>\n
        EXEC dbo.spGetCustomersWithSpecificProducts \"1,2,3,4,5,6\", , , , ''DEUTSCHLAND''<\/pre>\n
        Ausgabe des resultierenden SQL-Ausdrucks<\/h2>\n
        Wenn Fehler auftreten, die wir nicht nachvollziehen können, möchten wir einen Blick auf den zusammengestellten SQL-Ausdruck werfen.<\/p>\n
        Diesen können wir nach dem Zusammenstellen als eigenes Abfrageergebnis ausgeben lassen:<\/p>\n
        SELECT @SQL AS ''Generated SQL Code'';<\/pre>\n
        Diese Anweisung fügen wir einfach als letzte Anweisung in die CREATE PROCEDURE<\/b>– oder ALTER PROCEDURE<\/b>-Methode ein.<\/p>\n
        Dies liefert im SQL-Server ein Ergebnis vor dem eigentlichen Ergebnis (siehe Bild 8).<\/p>\n
        \"Ausgabe<\/p>\n
        Bild 8: Ausgabe des SQL-Ausdrucks<\/span><\/b><\/p>\n
        Rufen wir diese Abfrage nun von Access aus auf, erhalten wir nur das Resultat der ersten Abfrage als Ergebnis (siehe Bild 9). Dieses ist wesentlich besser lesbar, da es mit Zeilenumbrüchen dargestellt wird.<\/p>\n
        \"Ausgabe<\/p>\n
        Bild 9: Ausgabe in Access<\/span><\/b><\/p>\n
        Dynamische Abfrage mit optionalen Parametern von Access aus aufrufen<\/h2>\n
        Wenn wir diese gespeicherte Abfrage auf Basis von dynamischem SQL von Access aus aufrufen wollen, verwenden wir die gleiche Anweisung in der Pass-Through-Abfrage wie im SQL Server (siehe Bild 10).<\/p>\n
        \"Aufruf<\/p>\n
        Bild 10: Aufruf mit optionalen Parametern von Access aus<\/span><\/b><\/p>\n
        Aber wenn wir diese Abfrage von einem Formular aus zusammenstellen, sodass nur die angegebenen Parameter übergeben werden, müssen wir noch ein wenig VBA bemühen. Hier prüfen wir jeweils, ob der Benutzer einen Wert für den jeweiligen Parameter eingegeben hat und fügen zu einer Variablen wie strParameter<\/b> die einzelnen Name-Wert-Paare hinzu.<\/p>\n
        If <\/span>Not<\/span> IsNull(Me!txtBestelltVom) Then<\/span>\r\n     strParameter = strParameter & \", @DatumVon = ''\" _\r\n         & Format(Me.txtBestelltVom, \"yyyy-mm-dd\") & \"''\"\r\nEnd If<\/span>\r\nIf <\/span>Not<\/span> IsNull(Me!txtBestelltBis) Then<\/span>\r\n     strParameter = strParameter & \", @DatumBis = ''\" _\r\n         & Format(Me!txtBestelltBis, \"yyyy-mm-dd\") & \"''\"\r\nEnd If<\/span><\/pre>\n
        Die Zeichenkette für strParameter <\/b>müssen wir dann allerdings noch in die Pass-Through-Abfrage integrieren. Genau genommen können wir diese dann auch mit einer komplett neuen EXEC<\/b>-Anweisung füllen. Das sieht dann beispielsweise wie in Listing 3 aus. Hier untersuchen wir die einzelnen Steuerelemente des zu Beginn vorgestellten Formulars.<\/p>\n
        Private Sub <\/span>KundenAktualisieren()\r\n     Dim <\/span>db As <\/span>DAO.Database\r\n     Dim <\/span>qdf As <\/span>DAO.QueryDef\r\n     Dim <\/span>strSQL As String<\/span>\r\n     Dim <\/span>rst As <\/span>DAO.Recordset\r\n     Dim <\/span>rstSQL As <\/span>DAO.Recordset\r\n     Dim <\/span>strParameter As String<\/span>\r\n     Dim <\/span>strIN As String<\/span>\r\n     Set<\/span> db = CurrentDb\r\n     If <\/span>Not<\/span> Me!lstBestellteProdukte.ListCount = 0 Then<\/span>\r\n         Set<\/span> rst = db.OpenRecordset(\"SELECT ProduktID FROM tblBestellteProdukte\", dbOpenDynaset)\r\n         Do While<\/span> Not<\/span> rst.EOF\r\n             strIN = strIN & \", \" & rst!ProduktID\r\n             rst.MoveNext<\/span>\r\n         Loop<\/span>\r\n         If <\/span>Not<\/span> Len<\/span>(strIN) = 0 Then<\/span>\r\n             strIN = Mid<\/span>(strIN, 3)\r\n             strParameter = strParameter & \", @Produkte=''\" & strIN & \"''\"\r\n         End If<\/span>\r\n     End If<\/span>\r\n     strIN = \"\"\r\n     If <\/span>Not<\/span> Me.lstNichtBestellteProdukte.ListCount = 0 Then<\/span>\r\n         ''...Zusammenstellen der nicht bestellten Abonnements\r\n     End If<\/span>\r\n     If <\/span>Not<\/span> IsNull(Me!txtBestelltVom) Then<\/span>\r\n         strParameter = strParameter & \", @DatumVon = ''\" & Format(Me!txtBestelltVom, \"yyyy-mm-dd\") & \"''\"\r\n     End If<\/span>\r\n     If <\/span>Not<\/span> IsNull(Me!txtBestelltBis) Then<\/span>\r\n         strParameter = strParameter & \", @DatumBis = ''\" & Format(Me!txtBestelltBis, \"yyyy-mm-dd\") & \"''\"\r\n     End If<\/span>\r\n     If <\/span>Not<\/span> IsNull(Me!txtLand) Then<\/span>\r\n         strParameter = strParameter & \", @Land = ''\" & Me!txtLand & \"''\"\r\n     End If<\/span>\r\n     If <\/span>Not<\/span> Len<\/span>(strParameter) = 0 Then<\/span>\r\n         strParameter = Mid<\/span>(strParameter, 3)\r\n     End If<\/span>\r\n     strSQL = \"EXEC dbo.spGetCustomersWithSpecificProducts \" & strParameter\r\n     Set<\/span> qdf = db.QueryDefs(\"qrySPGetCustomersWithSpecificProducts\")\r\n     qdf.SQL = strSQL\r\n     On Error Resume Next<\/span>\r\n     Set<\/span> rstSQL = qdf.OpenRecordset(dbOpenDynaset)\r\n     If <\/span>Not<\/span> Err.Number = 0 Then<\/span>\r\n         Debug.Print<\/span> DBEngine.Errors(0), DBEngine.Errors(1)\r\n     End If<\/span>\r\n     On Error GoTo<\/span> 0\r\n     Set<\/span> Me!sfmKundenNachProduktenFiltern.Form.Recordset = rstSQL\r\nEnd Sub<\/span><\/pre>\n
        Listing 3: Zusammenstellen des Aufrufs der gespeicherten Prozedur mit optionalen Parametern<\/span><\/b><\/p>\n
        Zusammenfassung und Ausblick<\/h2>\n
        Komplizierte Abfragen auf Basis von per ODBC verknüpften Tabellen, deren Ausführung sehr lange brauchen, sind ein guter Grund, einen Schritt weiter zu gehen. Im Falle einer SQL Server-Migration heißt das: Wir bauen die Abfrage in einer gespeicherten Prozedur nach und rufen diese dann von Access aus auf. Dabei kann es sein, dass wir Parameter übergeben müssen.<\/p>\n
        Dies wird, wie dieser Beitrag zeigt, je nach Komplexität zu einer Fleißarbeit. In diesem Fall sowohl auf Seiten von Access, wo wir die Parameter aus den Benutzereingaben im Formular ermitteln müssen, als auch auf der SQL Server-Seite.<\/p>\n
        Hier prüfen wir, welche Parameter übergeben wurden, und integrieren sie in einer dynamisch zusammengestellten SQL-Abfrage. Deren Ergebnis liefern wir dann als Recordset an die aufrufende Access-Instanz zurück.<\/p>\n","protected":false},"excerpt":{"rendered":"
        Die einfache Migration der Tabellen einer Datenbank von Access zum SQL Server ist meist schnell erledigt. Der SQL Server Migration Assistant (SSMA) leistet gute Arbeit und schnell landen alle Tabellen in der SQL Server-Datenbank – samt Erstellung entsprechender Tabellenverknüpfungen im Access-Frontend. Damit lässt sich erst einmal arbeiten, da die Verknüpfungen Lesen und Schreiben der Daten wie gewohnt zulassen. Früher oder später wird man jedoch auf Abfragen im Access-Frontend stoßen, die schlicht zu langsam sind. Und hier kann der SQL Server sein wahres Potential ausspielen: Zum Beispiel, indem wir dort eine Stored Procedure (Gespeicherte Abfrage) anlegen, welche die Abfrage für uns direkt auf dem SQL Server ausführt, was viel schneller gehen wird. Und genau das ist Thema dieses Beitrags: Wie bekommen wir eine mehr oder weniger komplizierte Abfrage als Stored Procedure zum SQL Server und rufen diese von der Access-Datenbank aus auf?<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"_uf_show_specific_survey":0,"_uf_disable_surveys":false,"footnotes":""},"categories":[66022024,662024,44000022],"tags":[],"class_list":["post-55001491","post","type-post","status-publish","format-standard","hentry","category-66022024","category-662024","category-SQL_Server_und_Co"],"yoast_head":"\nSQL Server: Von der Abfrage zur Stored Procedure - Access im Unternehmen<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/access-im-unternehmen.de\/SQL_Server_Von_der_Abfrage_zur_Stored_Procedure\/\" \/>\n<meta property=\"og:locale\" content=\"de_DE\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"SQL Server: Von der Abfrage zur Stored Procedure\" \/>\n<meta property=\"og:description\" content=\"Die einfache Migration der Tabellen einer Datenbank von Access zum SQL Server ist meist schnell erledigt. Der SQL Server Migration Assistant (SSMA) leistet gute Arbeit und schnell landen alle Tabellen in der SQL Server-Datenbank - samt Erstellung entsprechender Tabellenverknüpfungen im Access-Frontend. Damit lässt sich erst einmal arbeiten, da die Verknüpfungen Lesen und Schreiben der Daten wie gewohnt zulassen. Früher oder später wird man jedoch auf Abfragen im Access-Frontend stoßen, die schlicht zu langsam sind. Und hier kann der SQL Server sein wahres Potential ausspielen: Zum Beispiel, indem wir dort eine Stored Procedure (Gespeicherte Abfrage) anlegen, welche die Abfrage für uns direkt auf dem SQL Server ausführt, was viel schneller gehen wird. Und genau das ist Thema dieses Beitrags: Wie bekommen wir eine mehr oder weniger komplizierte Abfrage als Stored Procedure zum SQL Server und rufen diese von der Access-Datenbank aus auf?\" \/>\n<meta property=\"og:url\" content=\"https:\/\/access-im-unternehmen.de\/SQL_Server_Von_der_Abfrage_zur_Stored_Procedure\/\" \/>\n<meta property=\"og:site_name\" content=\"Access im Unternehmen\" \/>\n<meta property=\"article:published_time\" content=\"2024-02-29T19:02:54+00:00\" \/>\n<meta property=\"og:image\" content=\"http:\/\/vg02.met.vgwort.de\/na\/5f008ae4b2a940bcb34e4024370481cf\" \/>\n<meta name=\"author\" content=\"Andr\u00e9 Minhorst\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Verfasst von\" \/>\n\t<meta name=\"twitter:data1\" content=\"Andr\u00e9 Minhorst\" \/>\n\t<meta name=\"twitter:label2\" content=\"Gesch\u00e4tzte Lesezeit\" \/>\n\t<meta name=\"twitter:data2\" content=\"22\u00a0Minuten\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/access-im-unternehmen.de\\\/SQL_Server_Von_der_Abfrage_zur_Stored_Procedure\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/access-im-unternehmen.de\\\/SQL_Server_Von_der_Abfrage_zur_Stored_Procedure\\\/\"},\"author\":{\"name\":\"Andr\u00e9 Minhorst\",\"@id\":\"https:\\\/\\\/access-im-unternehmen.de\\\/#\\\/schema\\\/person\\\/13395c4bcd7d7963efe33be9c584d93f\"},\"headline\":\"SQL Server: Von der Abfrage zur Stored Procedure\",\"datePublished\":\"2024-02-29T19:02:54+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/access-im-unternehmen.de\\\/SQL_Server_Von_der_Abfrage_zur_Stored_Procedure\\\/\"},\"wordCount\":3184,\"commentCount\":0,\"publisher\":{\"@id\":\"https:\\\/\\\/access-im-unternehmen.de\\\/#organization\"},\"image\":{\"@id\":\"https:\\\/\\\/access-im-unternehmen.de\\\/SQL_Server_Von_der_Abfrage_zur_Stored_Procedure\\\/#primaryimage\"},\"thumbnailUrl\":\"http:\\\/\\\/vg02.met.vgwort.de\\\/na\\\/5f008ae4b2a940bcb34e4024370481cf\",\"articleSection\":[\"2\\\/2024\",\"2024\",\"SQL Server und Co.\"],\"inLanguage\":\"de\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\\\/\\\/access-im-unternehmen.de\\\/SQL_Server_Von_der_Abfrage_zur_Stored_Procedure\\\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/access-im-unternehmen.de\\\/SQL_Server_Von_der_Abfrage_zur_Stored_Procedure\\\/\",\"url\":\"https:\\\/\\\/access-im-unternehmen.de\\\/SQL_Server_Von_der_Abfrage_zur_Stored_Procedure\\\/\",\"name\":\"SQL Server: Von der Abfrage zur Stored Procedure - Access im Unternehmen\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/access-im-unternehmen.de\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/access-im-unternehmen.de\\\/SQL_Server_Von_der_Abfrage_zur_Stored_Procedure\\\/#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/access-im-unternehmen.de\\\/SQL_Server_Von_der_Abfrage_zur_Stored_Procedure\\\/#primaryimage\"},\"thumbnailUrl\":\"http:\\\/\\\/vg02.met.vgwort.de\\\/na\\\/5f008ae4b2a940bcb34e4024370481cf\",\"datePublished\":\"2024-02-29T19:02:54+00:00\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/access-im-unternehmen.de\\\/SQL_Server_Von_der_Abfrage_zur_Stored_Procedure\\\/#breadcrumb\"},\"inLanguage\":\"de\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/access-im-unternehmen.de\\\/SQL_Server_Von_der_Abfrage_zur_Stored_Procedure\\\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"de\",\"@id\":\"https:\\\/\\\/access-im-unternehmen.de\\\/SQL_Server_Von_der_Abfrage_zur_Stored_Procedure\\\/#primaryimage\",\"url\":\"http:\\\/\\\/vg02.met.vgwort.de\\\/na\\\/5f008ae4b2a940bcb34e4024370481cf\",\"contentUrl\":\"http:\\\/\\\/vg02.met.vgwort.de\\\/na\\\/5f008ae4b2a940bcb34e4024370481cf\"},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/access-im-unternehmen.de\\\/SQL_Server_Von_der_Abfrage_zur_Stored_Procedure\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/access-im-unternehmen.de\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"SQL Server: Von der Abfrage zur Stored Procedure\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/access-im-unternehmen.de\\\/#website\",\"url\":\"https:\\\/\\\/access-im-unternehmen.de\\\/\",\"name\":\"Access im Unternehmen\",\"description\":\"Das Magazin f\u00fcr Datenbankentwickler auf Basis von Microsoft Access\",\"publisher\":{\"@id\":\"https:\\\/\\\/access-im-unternehmen.de\\\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/access-im-unternehmen.de\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"de\"},{\"@type\":\"Organization\",\"@id\":\"https:\\\/\\\/access-im-unternehmen.de\\\/#organization\",\"name\":\"Andr\u00e9 Minhorst Verlag\",\"url\":\"https:\\\/\\\/access-im-unternehmen.de\\\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"de\",\"@id\":\"https:\\\/\\\/access-im-unternehmen.de\\\/#\\\/schema\\\/logo\\\/image\\\/\",\"url\":\"https:\\\/\\\/access-im-unternehmen.de\\\/wp-content\\\/uploads\\\/2019\\\/09\\\/aiu_wp.png\",\"contentUrl\":\"https:\\\/\\\/access-im-unternehmen.de\\\/wp-content\\\/uploads\\\/2019\\\/09\\\/aiu_wp.png\",\"width\":370,\"height\":111,\"caption\":\"Andr\u00e9 Minhorst Verlag\"},\"image\":{\"@id\":\"https:\\\/\\\/access-im-unternehmen.de\\\/#\\\/schema\\\/logo\\\/image\\\/\"}},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/access-im-unternehmen.de\\\/#\\\/schema\\\/person\\\/13395c4bcd7d7963efe33be9c584d93f\",\"name\":\"Andr\u00e9 Minhorst\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"de\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/1b9d010cf1716692cb9c34f21554e07d17d461acaea5b61b8cb21cbec678d48a?s=96&d=mm&r=g\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/1b9d010cf1716692cb9c34f21554e07d17d461acaea5b61b8cb21cbec678d48a?s=96&d=mm&r=g\",\"contentUrl\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/1b9d010cf1716692cb9c34f21554e07d17d461acaea5b61b8cb21cbec678d48a?s=96&d=mm&r=g\",\"caption\":\"Andr\u00e9 Minhorst\"}}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"SQL Server: Von der Abfrage zur Stored Procedure - Access im Unternehmen","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/access-im-unternehmen.de\/SQL_Server_Von_der_Abfrage_zur_Stored_Procedure\/","og_locale":"de_DE","og_type":"article","og_title":"SQL Server: Von der Abfrage zur Stored Procedure","og_description":"Die einfache Migration der Tabellen einer Datenbank von Access zum SQL Server ist meist schnell erledigt. Der SQL Server Migration Assistant (SSMA) leistet gute Arbeit und schnell landen alle Tabellen in der SQL Server-Datenbank - samt Erstellung entsprechender Tabellenverknüpfungen im Access-Frontend. Damit lässt sich erst einmal arbeiten, da die Verknüpfungen Lesen und Schreiben der Daten wie gewohnt zulassen. Früher oder später wird man jedoch auf Abfragen im Access-Frontend stoßen, die schlicht zu langsam sind. Und hier kann der SQL Server sein wahres Potential ausspielen: Zum Beispiel, indem wir dort eine Stored Procedure (Gespeicherte Abfrage) anlegen, welche die Abfrage für uns direkt auf dem SQL Server ausführt, was viel schneller gehen wird. Und genau das ist Thema dieses Beitrags: Wie bekommen wir eine mehr oder weniger komplizierte Abfrage als Stored Procedure zum SQL Server und rufen diese von der Access-Datenbank aus auf?","og_url":"https:\/\/access-im-unternehmen.de\/SQL_Server_Von_der_Abfrage_zur_Stored_Procedure\/","og_site_name":"Access im Unternehmen","article_published_time":"2024-02-29T19:02:54+00:00","og_image":[{"url":"http:\/\/vg02.met.vgwort.de\/na\/5f008ae4b2a940bcb34e4024370481cf","type":"","width":"","height":""}],"author":"Andr\u00e9 Minhorst","twitter_card":"summary_large_image","twitter_misc":{"Verfasst von":"Andr\u00e9 Minhorst","Gesch\u00e4tzte Lesezeit":"22\u00a0Minuten"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/access-im-unternehmen.de\/SQL_Server_Von_der_Abfrage_zur_Stored_Procedure\/#article","isPartOf":{"@id":"https:\/\/access-im-unternehmen.de\/SQL_Server_Von_der_Abfrage_zur_Stored_Procedure\/"},"author":{"name":"Andr\u00e9 Minhorst","@id":"https:\/\/access-im-unternehmen.de\/#\/schema\/person\/13395c4bcd7d7963efe33be9c584d93f"},"headline":"SQL Server: Von der Abfrage zur Stored Procedure","datePublished":"2024-02-29T19:02:54+00:00","mainEntityOfPage":{"@id":"https:\/\/access-im-unternehmen.de\/SQL_Server_Von_der_Abfrage_zur_Stored_Procedure\/"},"wordCount":3184,"commentCount":0,"publisher":{"@id":"https:\/\/access-im-unternehmen.de\/#organization"},"image":{"@id":"https:\/\/access-im-unternehmen.de\/SQL_Server_Von_der_Abfrage_zur_Stored_Procedure\/#primaryimage"},"thumbnailUrl":"http:\/\/vg02.met.vgwort.de\/na\/5f008ae4b2a940bcb34e4024370481cf","articleSection":["2\/2024","2024","SQL Server und Co."],"inLanguage":"de","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/access-im-unternehmen.de\/SQL_Server_Von_der_Abfrage_zur_Stored_Procedure\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/access-im-unternehmen.de\/SQL_Server_Von_der_Abfrage_zur_Stored_Procedure\/","url":"https:\/\/access-im-unternehmen.de\/SQL_Server_Von_der_Abfrage_zur_Stored_Procedure\/","name":"SQL Server: Von der Abfrage zur Stored Procedure - Access im Unternehmen","isPartOf":{"@id":"https:\/\/access-im-unternehmen.de\/#website"},"primaryImageOfPage":{"@id":"https:\/\/access-im-unternehmen.de\/SQL_Server_Von_der_Abfrage_zur_Stored_Procedure\/#primaryimage"},"image":{"@id":"https:\/\/access-im-unternehmen.de\/SQL_Server_Von_der_Abfrage_zur_Stored_Procedure\/#primaryimage"},"thumbnailUrl":"http:\/\/vg02.met.vgwort.de\/na\/5f008ae4b2a940bcb34e4024370481cf","datePublished":"2024-02-29T19:02:54+00:00","breadcrumb":{"@id":"https:\/\/access-im-unternehmen.de\/SQL_Server_Von_der_Abfrage_zur_Stored_Procedure\/#breadcrumb"},"inLanguage":"de","potentialAction":[{"@type":"ReadAction","target":["https:\/\/access-im-unternehmen.de\/SQL_Server_Von_der_Abfrage_zur_Stored_Procedure\/"]}]},{"@type":"ImageObject","inLanguage":"de","@id":"https:\/\/access-im-unternehmen.de\/SQL_Server_Von_der_Abfrage_zur_Stored_Procedure\/#primaryimage","url":"http:\/\/vg02.met.vgwort.de\/na\/5f008ae4b2a940bcb34e4024370481cf","contentUrl":"http:\/\/vg02.met.vgwort.de\/na\/5f008ae4b2a940bcb34e4024370481cf"},{"@type":"BreadcrumbList","@id":"https:\/\/access-im-unternehmen.de\/SQL_Server_Von_der_Abfrage_zur_Stored_Procedure\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/access-im-unternehmen.de\/"},{"@type":"ListItem","position":2,"name":"SQL Server: Von der Abfrage zur Stored Procedure"}]},{"@type":"WebSite","@id":"https:\/\/access-im-unternehmen.de\/#website","url":"https:\/\/access-im-unternehmen.de\/","name":"Access im Unternehmen","description":"Das Magazin f\u00fcr Datenbankentwickler auf Basis von Microsoft Access","publisher":{"@id":"https:\/\/access-im-unternehmen.de\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/access-im-unternehmen.de\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"de"},{"@type":"Organization","@id":"https:\/\/access-im-unternehmen.de\/#organization","name":"Andr\u00e9 Minhorst Verlag","url":"https:\/\/access-im-unternehmen.de\/","logo":{"@type":"ImageObject","inLanguage":"de","@id":"https:\/\/access-im-unternehmen.de\/#\/schema\/logo\/image\/","url":"https:\/\/access-im-unternehmen.de\/wp-content\/uploads\/2019\/09\/aiu_wp.png","contentUrl":"https:\/\/access-im-unternehmen.de\/wp-content\/uploads\/2019\/09\/aiu_wp.png","width":370,"height":111,"caption":"Andr\u00e9 Minhorst Verlag"},"image":{"@id":"https:\/\/access-im-unternehmen.de\/#\/schema\/logo\/image\/"}},{"@type":"Person","@id":"https:\/\/access-im-unternehmen.de\/#\/schema\/person\/13395c4bcd7d7963efe33be9c584d93f","name":"Andr\u00e9 Minhorst","image":{"@type":"ImageObject","inLanguage":"de","@id":"https:\/\/secure.gravatar.com\/avatar\/1b9d010cf1716692cb9c34f21554e07d17d461acaea5b61b8cb21cbec678d48a?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/1b9d010cf1716692cb9c34f21554e07d17d461acaea5b61b8cb21cbec678d48a?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/1b9d010cf1716692cb9c34f21554e07d17d461acaea5b61b8cb21cbec678d48a?s=96&d=mm&r=g","caption":"Andr\u00e9 Minhorst"}}]}},"_links":{"self":[{"href":"https:\/\/access-im-unternehmen.de\/data\/wp\/v2\/posts\/55001491","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/access-im-unternehmen.de\/data\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/access-im-unternehmen.de\/data\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/access-im-unternehmen.de\/data\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/access-im-unternehmen.de\/data\/wp\/v2\/comments?post=55001491"}],"version-history":[{"count":0,"href":"https:\/\/access-im-unternehmen.de\/data\/wp\/v2\/posts\/55001491\/revisions"}],"wp:attachment":[{"href":"https:\/\/access-im-unternehmen.de\/data\/wp\/v2\/media?parent=55001491"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/access-im-unternehmen.de\/data\/wp\/v2\/categories?post=55001491"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/access-im-unternehmen.de\/data\/wp\/v2\/tags?post=55001491"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}