- \n
- tblKategorien:<\/b> die Warengruppen als zweistufige Hierarchie, über das Fremdschlüsselfeld OberKategorieID<\/b> auf sich selbst verwiesen<\/li>\n
- tblLieferanten:<\/b> sieben Lieferanten aus Deutschland, Österreich und der Schweiz<\/li>\n
- tblProdukte:<\/b> dreißig Produkte mit Preis, Lagerbestand, dem Ja\/Nein-Feld Auslaufartikel<\/b> und einer optionalen Beschreibung<\/li>\n
- tblKunden:<\/b> zweiunddreißig Kunden, teils Firmen, teils Privatpersonen, mit leeren Feldern und Sonderzeichen in den Namen<\/li>\n
- tblMitarbeiter:<\/b> acht Mitarbeiter, über VorgesetzterID<\/b> ebenfalls hierarchisch verknüpft<\/li>\n
- tblBestellstatus:<\/b> die fünf Bearbeitungsstufen einer Bestellung<\/li>\n
- tblBestellungen:<\/b> 330 Bestellungen von Januar 2024 bis September 2026<\/li>\n
- tblBestelldetails:<\/b> die 825 Positionen der Bestellungen<\/li>\n<\/ul>\n
Die Namen folgen einer festen Konvention: Tabellen beginnen mit tbl<\/b>, der Primärschlüssel einer Tabelle heißt wie die Tabelle in der Einzahl mit angehängtem ID<\/b> (etwa ProduktID<\/b> in tblProdukte<\/b>), und Fremdschlüsselfelder tragen denselben Namen wie das Feld, auf das sie verweisen (KategorieID<\/b> in tblProdukte<\/b> verweist auf tblKategorien<\/b>).<\/p>\n
Das Skript Bestellverwaltung_TSQL.sql<\/b> aus dem Download legt die Datenbank samt Daten an. Wir führen es in SQL Server Management Studio<\/b> (kurz SSMS) auf einer lokalen SQL Server Express<\/b>-Instanz aus.<\/p>\n
Es löscht eine vorhandene Datenbank gleichen Namens und erzeugt sie neu. Danach zeigt der Objekt-Explorer die acht Tabellen (siehe Bild 2).<\/p>\n
![\"Die](\"..\/fileadmin\/_temp_\/2026_04\/pic_516_001.png\")
<\/p>\nBild 1: Die Tabellen der Datenbank Bestellverwaltung_TSQL im Objekt-Explorer von SSMS<\/span><\/b><\/p>\n
Das Access-Frontend SQLServer_EinstiegVonJetSQLZuTSQL.accdb<\/b> enthält die acht Tabellen als Verknüpfungen mit den Namen dbo_tblKategorien<\/b>, dbo_tblKunden<\/b> und so weiter. Wie man solche Verknüpfungen von Hand oder per VBA anlegt, haben wir im Beitrag SQL Server: Tabellen per VBA verknüpfen<\/b> (www.vbentwickler.de\/485<\/b>) gezeigt.<\/p>\n
Das erste SELECT in SSMS<\/h2>\n
Ein Abfragefenster öffnen wir in SSMS mit Neue Abfrage<\/b>. Wichtig ist die Datenbank, gegen die die Anweisung läuft: Sie steht in der Auswahlliste links neben dem Ausführen-Schalter. Alternativ stellen wir der Anweisung ein USE Bestellverwaltung_TSQL<\/b> voran. Die folgende Abfrage liefert die ersten drei Kunden, alphabetisch nach Nachnamen sortiert:<\/p>\n
SELECT TOP (3) KundeID, Firma, Nachname, Ort\r\nFROM dbo.tblKunden\r\nORDER BY Nachname;<\/pre>\n
Fast alles daran kennen wir aus Access. Neu ist dbo<\/b>: Das ist das Schema, zu dem die Tabelle gehört. Jedes Objekt im SQL Server liegt in einem Schema, und wenn wir nichts anderes angelegt haben, heißt es dbo<\/b>. Das Semikolon am Ende empfiehlt Microsoft für jede Anweisung, und wir setzen es hier konsequent. Mit F5<\/b> oder dem Schalter Ausführen<\/b> erscheint das Ergebnis im Ergebnisbereich (siehe Bild 1).<\/p>\n
![\"Das](\"..\/fileadmin\/_temp_\/2026_04\/pic_516_002.png\")
<\/p>\nBild 2: Das erste SELECT im Abfragefenster von SSMS, darunter das Ergebnis<\/span><\/b><\/p>\n
Ein Wort zu GO<\/b>: In SSMS-Skripten stoßen wir ständig auf diese Zeile. GO<\/b> ist kein T-SQL-Befehl, sondern ein Trennzeichen für SSMS und das Kommandozeilenwerkzeug sqlcmd<\/b>.<\/p>\n
Es teilt ein Skript in einzelne Stapel (Batches), die nacheinander an den Server gehen. Das Skript der Beispieldatenbank nutzt es zum Beispiel, damit die Datenbank angelegt ist, bevor das erste CREATE TABLE<\/b> an sie gerichtet wird. In Pass-Through-Abfragen, die wir weiter unten kennenlernen, gehört GO<\/b> nicht hinein.<\/p>\n
Zeichenketten und Platzhalter<\/h2>\n
Der auffälligste Unterschied zeigt sich schon bei einem Textkriterium. In Access fassen wir Text in doppelte Anführungszeichen und verwenden *<\/b> und ?<\/b> als Platzhalter.<\/p>\n
Die Abfrage nach Kunden aus Köln, deren Nachname mit S beginnt, lautet in der SQL-Ansicht einer Access-Abfrage so:<\/p>\n
SELECT KundeID, Vorname, Nachname, Ort\r\nFROM dbo_tblKunden\r\nWHERE Ort = \"Köln\" AND Nachname Like \"S*\";<\/pre>\n
In T-SQL stehen Zeichenketten in einfachen Anführungszeichen, und die Platzhalter heißen %<\/b> für beliebig viele Zeichen und _<\/b> für genau ein Zeichen. Außerdem setzen wir vor Texte, die Umlaute oder andere Unicode-Zeichen enthalten können, das Präfix N<\/b>.<\/p>\n
Es kennzeichnet das Literal als Unicode-Text (nvarchar<\/b>) und verhindert, dass ein Zeichen durch die Zeichensatzumsetzung verloren geht. Die T-SQL-Fassung der Abfrage sieht so aus:<\/p>\n
SELECT KundeID, Vorname, Nachname, Ort\r\nFROM dbo.tblKunden\r\nWHERE Ort = N'Köln' AND Nachname LIKE N'S%';<\/pre>\n
Die doppelten Anführungszeichen sind in T-SQL nicht verboten, aber sie bedeuten etwas anderes: Bei eingeschaltetem QUOTED_IDENTIFIER<\/b> – das ist die Voreinstellung in SSMS und beim ODBC-Treiber – kennzeichnen sie einen Objektnamen, so wie bei Access die eckigen Klammern. Ein “Köln”<\/b> sucht der Server deshalb als Spaltennamen. Wie die Fehlermeldung dazu aussieht, sehen wir im Abschnitt über Pass-Through-Abfragen.<\/p>\n
Ein Apostroph im Text verdoppeln wir. Der Kunde Sean O’Brien findet sich so:<\/p>\n
SELECT KundeID, Vorname, Nachname\r\nFROM dbo.tblKunden\r\nWHERE Nachname = N'O''Brien';<\/pre>\n
Besonders tückisch ist der Platzhalter *<\/b>. Er löst keinen Fehler aus, er ist in T-SQL schlicht ein gewöhnliches Zeichen. Die Abfrage WHERE Nachname LIKE N’M*’<\/b> sucht daher nach Nachnamen, die genau auf M* enden, und liefert null Datensätze, statt Meier und Müller zu finden. Wer Abfragen aus Access übernimmt, sollte jedes Like<\/b> auf diese Platzhalter hin prüfen.<\/p>\n
Datumswerte<\/h2>\n
In Access schreiben wir Datumsliterale in Rautezeichen und im amerikanischen Format: #9\/15\/2026#<\/b>. T-SQL kennt diese Schreibweise nicht.<\/p>\n
Der Server beantwortet sie mit der Meldung Falsche Syntax in der Nähe von “#”<\/b>. Ein Datum steht in T-SQL als Zeichenkette in einfachen Anführungszeichen, und damit es unabhängig von den Spracheinstellungen des Servers richtig gelesen wird, schreiben wir es als ‘20260915’<\/b> (Jahr, Monat, Tag ohne Trennzeichen).<\/p>\n
Die zweite Falle betrifft die Uhrzeit. Die Spalte Bestelldatum<\/b> in tblBestellungen<\/b> hat den Datentyp datetime2(0)<\/b> und speichert Datum und Uhrzeit. Die Bestellung vom 15. September 2026 ist um 11:30:00 Uhr eingegangen. Eine Abfrage mit Gleichheit auf den Tag findet sie daher nicht, denn ‘20260915’<\/b> bedeutet Mitternacht. Drei Wege, die Bestellungen eines Tages zu zählen, vergleicht Listing 1.<\/p>\n
SELECT COUNT(*) FROM dbo.tblBestellungen\r\nWHERE Bestelldatum = '20260915';\r\nSELECT COUNT(*) FROM dbo.tblBestellungen\r\nWHERE Bestelldatum >= '20260915' AND Bestelldatum < '20260916';\r\nSELECT COUNT(*) FROM dbo.tblBestellungen\r\nWHERE CAST(Bestelldatum AS date) = '20260915';<\/pre>\n
Listing 1: Drei Wege, die Bestellungen eines Tages zu zählen<\/span><\/b><\/p>\n
Die erste Abfrage liefert 0, die zweite und die dritte liefern 1. Die zweite Schreibweise, ein halboffenes Intervall, ist die Standardlösung: Sie vergleicht das Feld unverändert mit Grenzwerten und lässt dem Server damit alle Möglichkeiten, einen Index zu nutzen.<\/p>\n
Die dritte ist bequemer zu lesen, wandelt aber den Feldinhalt um – bei anderen Umwandlungen als dem Schnitt auf das Datum kann der Server dann keinen Index mehr verwenden, wie wir im Teil über Indizes sehen werden.<\/p>\n
NULL und das Verketten von Texten<\/h2>\n
Mit NULL<\/b> verhält sich T-SQL grundsätzlich wie Access: Ein Vergleich mit NULL<\/b> ist weder wahr noch falsch. Das Kriterium WHERE Firma = NULL<\/b> liefert deshalb nie einen Datensatz, die Frage nach leeren Feldern lautet WHERE Firma IS NULL<\/b>. In der Beispieldatenbank sind bei sechzehn Kunden keine Firmen hinterlegt – die Privatkunden. Die Abfrage mit = NULL<\/b> zählt 0, die Abfrage mit IS NULL<\/b> zählt 16.<\/p>\n
Interessanter wird es beim Zusammensetzen von Texten. In Access gibt es zwei Operatoren: &<\/b> verkettet und behandelt Null<\/b> als leeren Text, +<\/b> verkettet und gibt Null<\/b> zurück, wenn ein Teil Null<\/b> ist. T-SQL hat nur +<\/b>, und der verhält sich wie das +<\/b> in Access. Hinzu kommt die Funktion CONCAT<\/b>, die NULL<\/b> wie einen leeren Text behandelt. Wir wollen Kunden als “Müller (Müller Bürobedarf GmbH)” anzeigen, Privatkunden dagegen nur mit dem Nachnamen. Listing 2 zeigt drei Varianten.<\/p>\n
SELECT TOP (4)\r\n Nachname + N' (' + Firma + N')' AS MitPlus,\r\n CONCAT(Nachname, N' (', Firma, N')') AS MitConcat,\r\n Nachname + ISNULL(N' (' + Firma + N')', N'') AS Sauber\r\nFROM dbo.tblKunden\r\nORDER BY KundeID;<\/pre>\nListing 2: Drei Varianten, Nachname und Firma zu verketten<\/span><\/b><\/p>\n
Bei Privatkunden liefert die erste Spalte NULL<\/b>, die zweite den unschönen Text “Schmidt ()” mit leeren Klammern, und erst die dritte Spalte ist richtig: Weil ein +<\/b> mit NULL<\/b> wieder NULL<\/b> ergibt, ist der gesamte Klammerausdruck NULL<\/b>, wenn die Firma fehlt, und ISNULL<\/b> ersetzt ihn durch einen leeren Text. Dieses Muster kennen Access-Entwickler schon, in Access schreiben wir es als Nachname & (” (” + Firma + “)”)<\/b>.<\/p>\n
Ja\/Nein, Zahlen und Datentypen<\/h2>\n
Für die Felder unserer Tabellen müssen wir wissen, welcher Access-Datentyp welchem SQL-Server-Typ entspricht. Die wichtigsten Zuordnungen:<\/p>\n
- \n
- AutoWert:<\/b> int<\/b> mit IDENTITY<\/b><\/li>\n
- Zahl (Long Integer):<\/b> int<\/b><\/li>\n
- Zahl (Integer):<\/b> smallint<\/b><\/li>\n
- Währung:<\/b> money<\/b> oder, besser kontrollierbar, decimal(9,2)<\/b><\/li>\n
- Ja\/Nein:<\/b> bit<\/b><\/li>\n
- Kurzer Text:<\/b> nvarchar(n)<\/b><\/li>\n
- Langer Text:<\/b> nvarchar(max)<\/b><\/li>\n
- Datum\/Uhrzeit:<\/b> date<\/b> für reine Datumswerte, datetime2<\/b> für Datum mit Uhrzeit<\/li>\n<\/ul>\n
Die Definition einer Tabelle liest der Server in Systemsichten aus. Die Abfrage aus Listing 3 zeigt die Spalten von tblProdukte<\/b> mit Typ, Länge und der Angabe, ob NULL<\/b> erlaubt ist.<\/p>\n
SELECT COLUMN_NAME, DATA_TYPE, CHARACTER_MAXIMUM_LENGTH AS Laenge, IS_NULLABLE\r\nFROM INFORMATION_SCHEMA.COLUMNS\r\nWHERE TABLE_NAME = N'tblProdukte'\r\nORDER BY ORDINAL_POSITION;<\/pre>\n
Listing 3: Die Spalten der Tabelle tblProdukte mit Datentyp und NULL-Zulässigkeit<\/span><\/b><\/p>\n
Das Ergebnis sehen wir in Bild 3.<\/p>\n
![\"Die](\"..\/fileadmin\/_temp_\/2026_04\/pic_516_003.png\")
<\/p>\nBild 3: Die Spalten von tblProdukte; bei Beschreibung steht die Länge -1 für nvarchar(max)<\/span><\/b><\/p>\n
Das Feld Auslaufartikel<\/b> ist ein bit<\/b>, in Access das Ja\/Nein-Feld. Dort ist Wahr<\/b> der Wert -1<\/b>, in T-SQL ist ein gesetztes bit<\/b> die 1<\/b>. Das hat konkrete Folgen: Die Bedingung WHERE Auslaufartikel = -1<\/b>, aus Access gewohnt, liefert in T-SQL keinen Fehler, aber auch keinen Datensatz.<\/p>\n
Die Bedingung WHERE Auslaufartikel = True<\/b> scheitert mit dem Fehler Ungültiger Spaltenname “True”<\/b>, denn T-SQL kennt kein True<\/b>. Richtig ist WHERE Auslaufartikel = 1<\/b>. Auch IIF(Auslaufartikel, …)<\/b> funktioniert nicht, weil ein bit<\/b> in T-SQL kein Wahrheitswert ist; dort muss ein Vergleich stehen.<\/p>\n
Funktionen: Was aus Access bleibt<\/h2>\n
Viele Funktionen, die wir in Access-Abfragen verwenden, stammen aus VBA und gibt es im SQL Server nicht. Die Datenbank-Engine kennt dafür eigene Gegenstücke. Eine erste Übersicht:<\/p>\n
- \n
- Nz:<\/b> ISNULL<\/b> oder COALESCE<\/b>; COALESCE<\/b> akzeptiert mehr als zwei Argumente und ist Standard-SQL<\/li>\n
- Iif:<\/b> IIF<\/b> in der Schreibweise von T-SQL (der Vergleich muss ausdrücklich stehen) oder die allgemeinere CASE WHEN … THEN … ELSE … END<\/b>-Anweisung<\/li>\n
- Format:<\/b> FORMAT<\/b> für Zahlen und Datumswerte, bei großen Mengen langsamer als CONVERT<\/b> mit Stilnummer<\/li>\n
- Date\/Now:<\/b> CAST(GETDATE() AS date)<\/b> beziehungsweise GETDATE<\/b> oder SYSDATETIME<\/b><\/li>\n
- Left\/Mid\/Len:<\/b> LEFT<\/b>, SUBSTRING<\/b> und LEN<\/b>; Mid<\/b> entspricht SUBSTRING<\/b> mit Startposition und Länge<\/li>\n
- InStr:<\/b> CHARINDEX<\/b>; die Parameter stehen in umgekehrter Reihenfolge (gesuchter Text zuerst)<\/li>\n
- DateAdd\/DateDiff:<\/b> DATEADD<\/b> und DATEDIFF<\/b>; der Datumsteil steht ohne Anführungszeichen, etwa DATEDIFF(DAY, Bestelldatum, Lieferdatum)<\/b><\/li>\n
- Year\/Month\/Day:<\/b> gleichnamige Funktionen<\/li>\n
- DLookup\/DSum\/DCount:<\/b> gibt es nicht; wir ersetzen sie durch Unterabfragen oder Verknüpfungen, davon handelt der dritte Teil<\/li>\n<\/ul>\n
Ein Beispiel mit drei dieser Funktionen zeigt Listing 4: die ersten vier Produkte mit Beschreibung, Auslauf-Kennzeichen und formatiertem Preis.<\/p>\n
SELECT TOP (4)\r\n Produkt,\r\n ISNULL(Beschreibung, N'(keine)') AS Beschreibung,\r\n IIF(Auslaufartikel = 1, N'ja', N'nein') AS Auslauf,\r\n FORMAT(Einzelpreis, 'N2', 'de-DE') AS Preis,\r\n Lagerbestand\r\nFROM dbo.tblProdukte\r\nORDER BY ProduktID;<\/pre>\n
Listing 4: Die Funktionen ISNULL, IIF und FORMAT in einer Abfrage<\/span><\/b><\/p>\n
Das Ergebnis steht in Bild 4. Das dritte Argument von FORMAT<\/b> legt die Kultur fest und damit Dezimalkomma und Tausenderpunkt unabhängig von der Spracheinstellung des Servers.<\/p>\n
![\"Die](\"..\/fileadmin\/_temp_\/2026_04\/pic_516_004.png\")
<\/p>\nBild 4: Die Produktliste mit ISNULL, IIF und FORMAT im Ergebnisraster von SSMS<\/span><\/b><\/p>\n
Warum Access-Abfragen auf SQL-Server-Tabellen scheitern können<\/h2>\n
Eine Abfrage wie die in Listing 5, die wir in Access für unsere Auswertung der Monatsumsätze 2026 anlegen würden, ist reines Access-SQL auf den verknüpften Tabellen.<\/p>\n
SELECT Format([b].[Bestelldatum],\"yyyy-mm\") AS Monat,\r\n Sum([d].[Menge]*[d].[Einzelpreis]*(1-[d].[Rabatt])) AS Umsatz\r\nFROM dbo_tblBestellungen AS b INNER JOIN dbo_tblBestelldetails AS d\r\n ON b.BestellungID = d.BestellungID\r\nWHERE b.Bestelldatum >= #1\/1\/2026# AND b.BestellstatusID <> 5\r\nGROUP BY Format([b].[Bestelldatum],\"yyyy-mm\")\r\nORDER BY Format([b].[Bestelldatum],\"yyyy-mm\");<\/pre>\n
Listing 5: Monatsumsätze 2026 in Access-SQL<\/span><\/b><\/p>\n
Sie steht als qryMonatsumsatzJet<\/b> im Frontend der Beispieldatenbank.<\/p>\n
Gegen eine reine Access-Tabelle würde die Abfrage sofort funktionieren. Auf den verknüpften SQL-Server-Tabellen öffnet sie sich mit einer Fehlermeldung (siehe Bild 5).<\/p>\n
![\"Access](\"..\/fileadmin\/_temp_\/2026_04\/pic_516_005.png\")
<\/p>\nBild 5: Access öffnet die Abfrage qryMonatsumsatzJet auf den verknüpften Tabellen nicht<\/span><\/b><\/p>\n
Der Grund liegt in den Datentypen: Access bindet die Spalte Bestelldatum<\/b>, die im Server ein datetime2(0)<\/b> ist, als Datum\/Uhrzeit, erweitert<\/b> ein, und mit diesem Typ kommt die Funktion Format<\/b> in einem Gruppierungsausdruck nicht zurecht.<\/p>\n
Ersetzen wir sie durch Year<\/b> und Month<\/b>, läuft die Abfrage. Auch die Dezimalfelder bergen Überraschungen: Die Summe Sum(Menge*Einzelpreis*(1-Rabatt))<\/b> über alle Positionen ohne Gruppierung scheitert mit der Meldung Staffelung des Dezimalwerts führte zu Datenkürzung<\/b>, und erst mit CCur<\/b> um den Ausdruck herum liefert Access ein Ergebnis. Solche Umwege kosten Zeit, und sie sind von Fall zu Fall verschieden.<\/p>\n
Das ist die Stelle, an der sich T-SQL lohnt: Statt die Abfrage so lange zu verbiegen, bis Access sie versteht, schicken wir sie an den Server, der sie ohne Umwege ausführt.<\/p>\n
Pass-Through-Abfragen in Access<\/h2>\n
Eine Pass-Through-Abfrage<\/b> reicht ihren Text unverändert an den Server weiter. Access prüft nichts, übersetzt nichts, es nimmt nur das Ergebnis entgegen. Wir legen sie über Erstellen\/Abfrageentwurf<\/b> an, schließen das Dialogfeld Tabelle anzeigen<\/b> und wählen im Tab Abfrageentwurf<\/b> den Schalter Pass-Through<\/b>. Danach tragen wir die T-SQL-Anweisung in die SQL-Ansicht ein. Für die Monatsumsätze lautet sie wie in Listing 6.<\/p>\n
SELECT FORMAT(b.Bestelldatum, 'yyyy-MM') AS Monat,\r\n SUM(d.Menge * d.Einzelpreis * (1 - d.Rabatt)) AS Umsatz\r\nFROM dbo.tblBestellungen b\r\n INNER JOIN dbo.tblBestelldetails d ON d.BestellungID = b.BestellungID\r\nWHERE b.Bestelldatum >= '20260101' AND b.BestellstatusID <> 5\r\nGROUP BY FORMAT(b.Bestelldatum, 'yyyy-MM')\r\nORDER BY Monat;<\/pre>\n
Listing 6: Monatsumsätze 2026 in T-SQL<\/span><\/b><\/p>\n
Damit Access weiß, wohin es die Anweisung schicken soll, müssen wir die Eigenschaft ODBC-Verbindung<\/b> im Eigenschaftenblatt der Abfrage füllen (siehe Bild 6).<\/p>\n
![\"Die](\"..\/fileadmin\/_temp_\/2026_04\/pic_516_006.png\")
<\/p>\nBild 6: Die Pass-Through-Abfrage ptMonatsumsatz im Entwurf, mit der Eigenschaft ODBC-Verbindung im Eigenschaftenblatt<\/span><\/b><\/p>\n
Sie enthält Treiber, Server, Datenbank und die Art der Anmeldung, in unserem Fall wie in Listing 7.<\/p>\n
ODBC;DRIVER={ODBC Driver 18 for SQL Server};SERVER=.\\SQLEXPRESS;\r\nDATABASE=Bestellverwaltung_TSQL;Trusted_Connection=Yes;TrustServerCertificate=Yes;<\/pre>\nListing 7: Die ODBC-Verbindungszeichenfolge für SQL Server Express<\/span><\/b><\/p>\n
In der Eigenschaft steht die Zeichenfolge in einer einzigen Zeile. Trusted_Connection=Yes<\/b> meldet uns mit dem Windows-Konto an, TrustServerCertificate=Yes<\/b> akzeptiert das Zertifikat des lokalen Servers. Beim Treiber 18 ist die Verschlüsselung standardmäßig eingeschaltet, ohne diese Angabe scheitert die Verbindung bei einem Server ohne vertrauenswürdiges Zertifikat. Bei einem Server im Produktivbetrieb gehört ein gültiges Zertifikat auf den Server, nicht die Abkürzung in die Zeichenfolge.<\/p>\n
Die Abfrage liefert jetzt die Monatsumsätze als normales Datenblatt (siehe Bild 7).<\/p>\n
![\"Das](\"..\/fileadmin\/_temp_\/2026_04\/pic_516_007.png\")
<\/p>\nBild 7: Das Ergebnis der Pass-Through-Abfrage ptMonatsumsatz<\/span><\/b><\/p>\n
Für die Arbeit mit Pass-Through-Abfragen sollten wir zwei Eigenschaften im Hinterkopf behalten. Das Ergebnis ist immer schreibgeschützt, weil Access keine Verbindung zu einer Tabelle hat, in die es zurückschreiben könnte.<\/p>\n
Und es gibt keine Parameter: Wer Kriterien einfügen möchte, muss den Text der Anweisung vor dem Ausführen zusammensetzen. Genau das erledigen wir im nächsten Abschnitt in VBA.<\/p>\n
Für Aktionsabfragen, die nichts zurückliefern (UPDATE<\/b>, DELETE<\/b>), setzen wir die Eigenschaft Datensätze zurückgeben<\/b> auf Nein<\/b>.<\/p>\n
T-SQL aus VBA zusammensetzen<\/h2>\n
In VBA erzeugen wir Pass-Through-Abfragen mit einem temporären QueryDef<\/b> ohne Namen. Das Muster steckt in wenigen kleinen Funktionen im Modul mdlTSQLEinstiegBeispiele<\/b>.<\/p>\n
Zuerst die Hilfsfunktionen für Literale, die die Unterschiede aus den vorigen Abschnitten in sich aufnehmen: SqlText<\/b> verdoppelt Apostrophe, setzt das N<\/b>-Präfix und macht aus Null<\/b> das T-SQL-Schlüsselwort NULL<\/b>, SqlDatum<\/b> liefert ein sprachunabhängiges Datumsliteral (siehe Listing 8).<\/p>\n
Public Function <\/span>SqlText(varWert As Variant<\/span>) As String<\/span>\r\n If <\/span>IsNull(varWert) Then<\/span>\r\n SqlText = \"NULL\"\r\n Else<\/span>\r\n SqlText = \"N'\" & Replace<\/span>(CStr(varWert), \"'\", \"''\") & \"'\"\r\n End If<\/span>\r\nEnd Function<\/span>\r\nPublic Function <\/span>SqlDatum(varWert As Variant<\/span>) As String<\/span>\r\n If <\/span>IsNull(varWert) Then<\/span>\r\n SqlDatum = \"NULL\"\r\n Else<\/span>\r\n SqlDatum = \"'\" & Format(varWert, \"yyyymmdd\") & \"'\"\r\n End If<\/span>\r\nEnd Function<\/span><\/pre>\nListing 8: Die Hilfsfunktionen SqlText und SqlDatum<\/span><\/b><\/p>\n
Beide Funktionen nehmen einen Variant<\/b> entgegen, damit auch ein leeres Feld aus einem Recordset unbeschadet durchkommt. Die Funktion SqlDatum<\/b> gibt bewusst nur das Datum zurück; wer die Uhrzeit braucht, nimmt die Schwesterfunktion SqlDatumZeit<\/b>, die ein Literal im ISO-Format ‘2026-09-05T14:30:05’<\/b> liefert. Mit ihnen bauen wir den Text einer Pass-Through-Abfrage und führen ihn über die zweite Gruppe von Funktionen aus, die in Listing 9 stehen.<\/p>\n
Public Function <\/span>PassThroughOeffnen(strSQL As String<\/span>) As <\/span>DAO.Recordset\r\n Dim <\/span>qdf As <\/span>DAO.QueryDef\r\n Set<\/span> qdf = CurrentDb.CreateQueryDef(\"\")\r\n qdf.Connect = cstrVerbindung\r\n qdf.SQL = strSQL\r\n qdf.ReturnsRecords = True<\/span>\r\n Set<\/span> PassThroughOeffnen = qdf.OpenRecordset(dbOpenSnapshot, dbSQLPassThrough)\r\nEnd Function<\/span>\r\nPublic Function <\/span>PassThroughWert(strSQL As String<\/span>) As Variant<\/span>\r\n Dim <\/span>rst As <\/span>DAO.Recordset\r\n Set<\/span> rst = PassThroughOeffnen(strSQL)\r\n If <\/span>rst.EOF Then<\/span>\r\n PassThroughWert = Null\r\n Else<\/span>\r\n PassThroughWert = rst.Fields(0).Value\r\n End If<\/span>\r\n rst.Close\r\nEnd Function<\/span><\/pre>\nListing 9: PassThroughOeffnen und PassThroughWert<\/span><\/b><\/p>\n
PassThroughOeffnen<\/b> legt eine QueryDef<\/b> mit dem Namen “”<\/b> an. Das ist in DAO der Hinweis, dass die Abfrage nur im Arbeitsspeicher existiert und nicht in der Datenbank gespeichert wird.<\/p>\n
Die Eigenschaft Connect<\/b> nimmt die Verbindungszeichenfolge aus der Konstante cstrVerbindung<\/b> im Kopf des Moduls auf, die wir bei Bedarf auf den eigenen Server anpassen. dbSQLPassThrough<\/b> im Aufruf von OpenRecordset<\/b> stellt sicher, dass Access den Text nicht doch selbst verarbeitet. PassThroughWert<\/b> ist die kleine Schwester: Sie liefert nur den ersten Wert der ersten Zeile und eignet sich für Zählungen und Nachschlagewerte.<\/p>\n
Mit diesen Bausteinen schreiben wir Funktionen wie BestellungenEinesTages<\/b> und KundenZaehlen<\/b> aus Listing 10. Die erste zählt die Bestellungen eines Tages und nutzt das halboffene Intervall aus dem Abschnitt über Datumswerte.<\/p>\n
Public Function <\/span>BestellungenEinesTages(datTag As Date<\/span>) As Long<\/span>\r\n Dim <\/span>strSQL As String<\/span>\r\n strSQL = \"SELECT COUNT(*) FROM dbo.tblBestellungen WHERE Bestelldatum >= \" & SqlDatum(datTag) & _\r\n \" AND Bestelldatum < \" & SqlDatum(datTag + 1)\r\n BestellungenEinesTages = Nz(PassThroughWert(strSQL), 0)\r\nEnd Function<\/span>\r\nPublic Function <\/span>KundenZaehlen(strAnfang As String<\/span>) As Long<\/span>\r\n Dim <\/span>strSQL As String<\/span>\r\n strSQL = \"SELECT COUNT(*) FROM dbo.tblKunden WHERE Nachname LIKE \" & SqlText(strAnfang & \"%\")\r\n KundenZaehlen = Nz(PassThroughWert(strSQL), 0)\r\nEnd Function<\/span><\/pre>\nListing 10: BestellungenEinesTages und KundenZaehlen<\/span><\/b><\/p>\n
Im Direktbereich liefert Debug.Print BestellungenEinesTages(#9\/15\/2026#)<\/b> die 1, Debug.Print KundenZaehlen(“O’Brien”)<\/b> ebenfalls die 1 – der Apostroph geht dank SqlText<\/b> ohne Beanstandung durch.<\/p>\n
Ein Stolperstein bleibt: Das Prozentzeichen im Suchbegriff wirkt als Platzhalter. KundenZaehlen(“%”)<\/b> zählt alle zweiunddreißig Kunden. Für eine Suchfunktion, die Benutzereingaben entgegennimmt, müssen wir diese Zeichen entweder maskieren oder die Suche an eine gespeicherte Prozedur mit Parametern übergeben, wie wir es im Teil über Prozeduren zeigen.<\/p>\n
Das gilt umso mehr, als eine zusammengesetzte Anweisung generell angreifbar ist: Wer Eingaben ungeprüft in den SQL-Text übernimmt, öffnet die Tür für SQL-Injection. SqlText<\/b> entschärft das für Text, indem es Apostrophe verdoppelt, ersetzt aber keine Parameter. Für alles, was Benutzer frei eingeben, sind gespeicherte Prozeduren mit Parametern die bessere Wahl (siehe die Beiträge ADODB: Gespeicherte Prozeduren ausführen<\/b> (www.vbentwickler.de\/503<\/b>), und ADODB: Gespeicherte Prozeduren einfach aufrufen<\/b> (www.vbentwickler.de\/505<\/b>).<\/p>\n
Fehlermeldungen des Servers lesen<\/h2>\n
Läuft eine Pass-Through-Abfrage in einen Fehler, meldet VBA nur: ODBC-Aufruf fehlgeschlagen.<\/b> Das ist die Antwort von Access, nicht die des Servers. Die eigentliche Meldung steckt in der Auflistung DBEngine.Errors<\/b>. Die Funktion in Listing 11 sammelt sie ein, schneidet die Präfixe des Treibers in eckigen Klammern ab und gibt die Meldungen als Text zurück:<\/p>\n
Public Function <\/span>PassThroughFehler(strSQL As String<\/span>) As String<\/span>\r\n Dim <\/span>varDummy As Variant<\/span>\r\n Dim <\/span>errFehler As <\/span>DAO.Error\r\n Dim <\/span>strText As String<\/span>\r\n On Error GoTo<\/span> ErrHandler\r\n varDummy = PassThroughWert(strSQL)\r\n - Iif:<\/b> IIF<\/b> in der Schreibweise von T-SQL (der Vergleich muss ausdrücklich stehen) oder die allgemeinere CASE WHEN … THEN … ELSE … END<\/b>-Anweisung<\/li>\n
- Zahl (Long Integer):<\/b> int<\/b><\/li>\n
- tblLieferanten:<\/b> sieben Lieferanten aus Deutschland, Österreich und der Schweiz<\/li>\n