<\/p>\n
Wussten Sie, dass „Query“ ins Deutsche übersetzt „Abfragen“ heißt Natürlich wussten Sie das. Es ist ja auch die korrekte Bezeichnung, wenn es um Datenbanken geht. Aber wussten Sie auch, dass „Query“ ebenso für „Rückfrage“ und sogar für „Reklamation“ steht ähnlich ist es mit dem Verb: „to query“ wird als „abfragen“, aber auch als „bezweifeln“ und „in Frage stellen“ verstanden. Nun sollen die Ergebnisse von Access-Abfragen natürlich weder bezweifelt noch in Frage gestellt werden; auch nicht, wenn die Abfragen auf einen SQL Server zugreifen. Aber die Antwortzeiten solcher Abfragen werden Sie in manchen Fällen durchaus bezweifeln. Auch die Vorgehensweise, mit der Access die Daten vom SQL Server anfordert, kann in Frage gestellt werden.<\/b><\/p>\n
Access bietet mit seinen Abfragen ein umfangreiches Tool, um Daten aus verschiedenen Tabellen miteinander zu verknüpfen, auf die wesentlichen Daten zu reduzieren und sie aufzubereiten. Doch die Abfragen haben ihre Tücken, wenn sie auf eingebundene Tabellen des SQL Servers zugreifen.<\/p>\n
Der Grund hierfür ist recht einfach: Die eingebundenen Tabellen werden von der Jet-Engine nicht als SQL Server-Tabellen, sondern wie Access-Tabellen gehandhabt. Jede Abfrage wird über die Jet-Engine an den SQL Server übergeben. Und die Jet-Engine entscheidet, welche Daten in welcher Menge vom SQL Server angefordert werden. Das kann bei einfachen Abfragen eine gute, bei etwas komplizierteren Abfragen eine eher schlechte Entscheidung sein. <\/p>\n
„Kompliziert“ ist in einem solchen Fall relativ. Die Abfragen müssen nicht unbedingt komplex sein; ein einfaches SELECT <\/b>auf eine Tabelle mit einem Verweis auf ein Formularfeld in der WHERE<\/b>-Bedingung reicht schon, um die Jet-Engine dazu zu veranlassen, sicherheitshalber alle Daten der dieser Abfrage zugrundeliegenden SQL Server-Tabellen anzufordern.<\/p>\n
Bei kleinen Tabellen mag das nicht relevant sein. Aber Sie arbeiten ja mit dem SQL Server als Backend, weil Sie große Datenmengen bearbeiten wollen. Insofern sollten Sie prüfen, wann in welchem Umfang Daten über das Netzwerk angefordert werden. Doch dazu müssen Sie zunächst wissen, wie die Jet-Engine bei der Anforderung der Daten vorgeht.<\/p>\n
Für jede Access-Abfrage erstellt die Jet-Engine einen Ausführungsplan, anhand dessen der Access-Abfrageoptimierer die optimale Vorgehensweise zur Ausführung der Abfrage ermittelt.<\/p>\n
Dies gilt sowohl für Abfragen auf Access-Tabellen, wie auch auf in Access eingebundene SQL Server-Tabellen. <\/p>\n
Gerade bei Abfragen auf SQL Server-Tabellen ist das Ergebnis des Abfrageoptimierers entscheidend für die Art und Weise, wie die Daten vom SQL Server angefordert werden. <\/p>\n
Im Grunde genommen gibt es für die Ermittlung der Daten vom SQL Server drei Varianten:<\/p>\n
Wie Sie sehen, sind das nicht gerade die schönsten Aussichten, was den Netzwerk-Traffic zwischen Access und SQL Server betrifft.<\/p>\n
Um den Netzwerk-Traffic nicht gänzlich in die Hände der Jet-Engine zu legen, müssen Sie die Access-Abfragen anpassen. <\/p>\n
Für diese Anpassungen ist es sinnvoll zu wissen, wann der Abfrageoptimierer die Abfrage in welcher Form an den SQL Server übergibt. <\/p>\n
Dies ist grundsätzlich von der Abfrage selbst abhängig. Es gibt einige Gründe für eher suboptimale Entscheidungen des Abfrageoptimierers:<\/p>\n
SELECT dbo_Orders.OrderID,\r\ndbo_Orders.Freight\r\nFROM dbo_Orders\r\nWHERE dbo_Orders.Freight) > DMax("UnitPrice","dbo_Order Details")<\/pre>\nwird in zwei einzelne Anweisungen gesplittet:<\/p>\n
SELECT MAX("UnitPrice") FROM "dbo"."Order Details"<\/pre>\nund<\/p>\n
SELECT "Freight" "dbo"."Orders"."OrderID"\r\nFROM "dbo"."Orders"<\/pre>\nAccess übernimmt das Verknüpfen der beiden übertragenen Ergebnismengen.<\/p>\n
Es gibt noch weitere Gründe für den Abfrageoptimierer, die Abfrage nicht 1:1 oder nur teilweise an den SQL Server zu übergeben, wie beispielsweise <\/p>\n
Grundsätzlich handelt der Abfrageoptimierer also nach der altbekannten Bauernregel „Was der Bauer nicht kennt, isst er nicht“. Ergo werden nur Abfragen an den SQL Server übergeben, bei denen der Abfrageoptimierer der Meinung ist, dass der SQL Server – oder auch die OBDC-Schnittstelle – diese interpretieren kann.<\/p>\n
In welcher Art und Weise die anderen Abfragen am SQL Server ankommen, liegt in der Hand des Abfrageoptimierers. Und den sollten Sie im Auge behalten. Denn wenn die Abfrage nicht auf dem SQL Server ausgeführt wird, sondern für die Ausführung die kompletten Daten oder Teile davon an den Client übertragen werden, degradiert Access Ihre mühsam erstellte Client\/Server-Applikation zu einem File-Server-System.<\/p>\n
<\/p>\n
Bleibt die Frage, wie Sie den Abfrageoptimierer beobachten können. Dabei kann Ihnen nun wieder der SQL Server helfen – oder besser gesagt ein Tool des SQL Servers: der Profiler.<\/p>\n
Der Profiler<\/p>\n
Jede Anweisung, die der SQL Server ausführt, kann mit dem Profiler aufgezeichnet werden. Sie sehen also nicht, wie Access die Abfragen optimiert, aber Sie sehen, welche Anweisungen der SQL Server ausführt. <\/p>\n
Sofern Sie die Aufzeichnung auf Ihre Access-Applikation eingrenzen, können Sie also verfolgen, welche Anweisungen SQL Server von Access erhält und ausführt, das heißt, Sie sehen, ob Access nun die komplette Abfrage oder nur Teile oder – im schlimmsten Fall – einfache SELECT<\/b>-Anweisungen zur Ermittlung der kompletten Tabelleninhalte an den SQL Server übergibt.<\/p>\n
Um die Abfragen aufzuzeichnen, starten Sie zunächst den Profiler, den Sie in der Programmgruppe des SQL Servers finden. Dort richten Sie eine Ablaufverfolgung ein, indem Sie im Menü Datei <\/b>den Befehl Neue Ablaufverfolgung <\/b>wählen und sich anschließend auf dem SQL Server anmelden, auf den Sie per Access zugreifen möchten.<\/p>\n
Im Dialog Ablaufverfolgungseigenschaften <\/b>geben Sie der Ablaufverfolgung im Feld Ablaufverfolgungsname <\/b>eine Bezeichnung und wählen danach die Ablaufverfolgungsvorlage Leer <\/b>aus dem Listenfeld Vorlage verwenden <\/b>(siehe Bild 1). Anschließend wechseln Sie zur Registerkarte Ereignisauswahl<\/b>.<\/p>\n Typ der Access-Abfrage<\/p>\n Objekt im SQL Server<\/p>\n<\/thead>\n Tab. 1: Access-Abfragen im SQL Server<\/span><\/b><\/p>\n<\/tfoot>\n Bild 1: Definition der Ablaufverfolgung<\/span><\/b><\/p>\n Zum Aufzeichnen der von Access an den SQL Server übergebenen Anweisungen reicht das Ereignis SQL:StmtCompleted <\/b>aus der Ereignisgruppe TSQL<\/b> vollkommen aus <\/b>(siehe Bild 2). <\/p>\n Bild 2: Auswahl der Ereignisse<\/span><\/b><\/p>\n Um nicht alle Aktivitäten aller Datenbanken des SQL Servers in der Ablaufverfolgung aufzuzeichnen, müssen Sie noch über die Schaltfläche Spaltenfilter die Ablaufverfolgung auf die Datenbank – in diesem Beispiel die Datenbank „Northwind“ – eingrenzen. <\/p>\n Dazu ermitteln Sie zunächst im SQL Server Management Studio mit SELECT DB_ID('Northwind') <\/b>die ID der Datenbank und tragen diese in den Filter Datenbank-Id ein (siehe Bild 3).<\/p>\n Bild 3: Definition des Filters<\/span><\/b><\/p>\n Schließen Sie den Dialog Filter bearbeiten <\/b>mit OK <\/b>und starten Sie anschließend die Ablaufverfolgung mit einem Klick auf Ausführen<\/b>. Der Profiler zeichnet nun alle Anweisungen auf, die an die Datenbank „Northwind“ übergeben werden und zeigt diese im Ausgabefenster an (siehe Bild 4).<\/p>\n Bild 4: Die Ablaufverfolgung<\/span><\/b><\/p>\n Jetzt müssen Sie nur noch in Access die entsprechenden Abfragen ausführen und sich im Profiler die jeweiligen Anweisungen anschauen. So können Sie bei jeder Abfrage prüfen, in welcher Art und Weise diese an den SQL Server übergeben wird.<\/p>\n Anhand dieser Informationen können Sie dann Ihre Access-Abfragen ändern, um einen besseren Ausführungsplan zu erzielen oder aber – und das ist die bessere Variante – Sie verlagern Ihre Access-Abfragen auf den SQL Server. <\/p>\n Dadurch wird die Abfrage auf dem SQL Server ausgeführt und Access erhält nur die ermittelten Datensätze. <\/p>\n Das bringt einiges an Performance, denn <\/p>\n Was aber bietet der SQL Server an Möglichkeiten, die den Access-Abfragen am nächsten kommen Vergleicht man den Abfragedesigner von Access mit dem des SQL Servers, fällt die Wahl auf den ersten Blick auf die Sichten. Doch bevor Sie sich nun ohne weiterzulesen direkt an das Umsetzen der Abfragen zu Sichten machen, sollten Sie sich bewusst sein, was die Sichten des SQL Servers wirklich sind.<\/pre>\n Sichten sind den Abfragen von Access zwar ähnlich, denn auch hier werden mehrere Zeilen und Spalten von einer oder mehreren Tabellen zur Laufzeit ermittelt, aber im Vergleich zur Funktionalität von Access-Abfragen sind die Sichten des SQL Servers stark eingeschränkt. <\/p>\n Um die Funktionalität der Access-Abfragen im SQL Server abbilden zu können, reichen die Sichten alleine nicht aus. Für die Umsetzung von Access-Abfragen müssen beim SQL Server bis zu drei verschiedene Komponenten genutzt werden: Sichten<\/b>, gespeicherte Prozeduren <\/b>und benutzerdefinierte Funktionen<\/b>.<\/p>\n Im Grunde genommen sind Sichten wie virtuelle Tabellen zu verstehen, die das Ergebnis einer SELECT<\/b>-Anweisung liefern. Sichten werden nach der ersten Ausführung im Ausführungscache gespeichert und stehen somit schneller zur Verfügung.<\/p>\n Sichten sind von der Struktur her sehr einfach, was auch die Einschränkungen erklärt. So können Sichten keine Parameter enthalten und sofern die Sicht komplexere Tabellenverknüpfungen enthält, können die Daten der zugrundeliegenden Tabellen über die Sicht nicht ändert werden.<\/p>\n In Access werden die Sichten nicht als Sichten unterstützt, sondern als Tabellen. Sichten müssen in Access wie Tabellen eingebunden werden, das heißt, sofern die Daten über die Sicht manipuliert werden sollen, muss beim Einbinden der Sicht ein Primärschlüssel vergeben werden.<\/p>\n Natürlich muss die für den Primärschlüssel ausgewählte Spalte eindeutige Werte enthalten. Nach dem Einbinden stehen die Sichten in Access als eingebundene Tabellen zur Verfügung.<\/p>\n Gespeicherte Prozeduren<\/p>\n ähnlich wie bei Sichten gibt es auch für gespeicherten Prozeduren einen Ausführungscache, den Procedure-Cache. Hier werden die Ausführungen der gespeicherten Prozeduren gespeichert und wiederverwendet. <\/p>\n Gespeicherte Prozeduren werden in T-SQL geschrieben und können nicht nur Ergebnismengen liefern, sondern auch Daten manipulieren. Durch diese Flexibilität sind gespeicherte Prozeduren optimal zur Prüfung von Geschäftsregeln und zur Kapselung beziehungsweise Standardisierung von Datenmanipulationen. Dabei sind im Gegensatz zu den Sichten auch Ein- und Ausgabe-Parameter möglich.<\/p>\n Es gibt aber auch Einschränkungen: Gespeicherte Prozeduren können nicht in einer SELECT<\/b>-Anweisung, in einer Sicht oder in einer benutzerdefinierten Funktion verwendet werden.<\/p>\n Hier gibt es zwei verschiedene Typen: Die Tabellen-Funktionen und die Skalar-Funktionen. Eine Tabellen-Funktion gibt immer eine Ergebnismenge zurück. Tabellen-Funktionen können wie Sichten oder Tabellen in einer Tabellenverknüpfung verwendet werden, mit dem Vorteil, dass Tabellenfunktionen Parameter unterstützen. Skalar-Funktionen hingegen liefern immer nur einen einzigen Wert. Skalar-Funktionen unterstützen ebenfalls Parameter und können in WHERE<\/b>-Bedingungen oder in SELECT<\/b>-Anweisungen als Spalte genutzt werden. Beide Typen können in gespeicherten Prozeduren und in Sichten verwendet werden.<\/p>\n Sie sehen schon, so einfach wird das mit dem „Verlagern der Abfragen auf den SQL Server“ nicht. Um Access-Abfragen als Sichten, gespeicherte Prozeduren und benutzerdefinierte Funktionen auf dem SQL Server anzulegen, müssen Sie vor allem eines beherrschen: T-SQL.<\/p>\n Ohne Kenntnisse in T-SQL werden Sie die Abfragen nicht adäquat umsetzen können. Denn auch in T-SQL ist es durchaus möglich, langsame Abfragen zu programmieren. <\/p>\n Um die Abfragen auf den SQL Server zu verlagern, ohne dass Sie tiefere T-SQL-Kenntnisse besitzen, gibt es noch eine weitere, wenn auch nicht immer zufriedenstellende Möglichkeit: Migrieren Sie Ihre MDB in eine ADP. Nein – das ist jetzt kein Aufruf zur Verwendung von ADPs. Aber auf diesem Weg können Sie sich vom Upsizing-Assistenten die Access-Abfragen als Sichten, gespeicherte Prozeduren und benutzerdefinierte Funktionen erstellen lassen. Diese SQL Server-Komponenten können Sie als Vorlage nutzen und die ADP nach der Migration wieder löschen.<\/p>\n Zugegeben – die Ergebnisse der Migration sind nicht immer optimal. Aber für einen Einblick, wie welche Access-Abfrage in welche SQL Server-Komponente umgesetzt wird, sind sie allemal ausreichend. Eventuell haben Sie auch mit den erstellten Komponenten schon einen Performance-Vorteil. Und wenn nicht, können Sie Sichten, gespeicherte Prozeduren und benutzerdefinierten Funktionen jederzeit nachträglich optimieren. Falls Sie den Weg über die ADP nicht gehen möchten, enthält Tabelle 1 eine Übersicht, welche Access-Abfragetypen vom Upsizing-Assistenten in welche SQL Server-Komponenten übersetzt werden. Diese Tabelle können Sie als Richtlinie für die manuelle Umsetzung der Access-Abfragen zu SQL Server-Komponenten nutzen.<\/p>\n Der Upsizing-Assistent kann nicht alle Access-Abfragen umsetzen. Es gibt einige Konstrukte, die in Access einwandfrei funktionieren, aber nicht im SQL Server. Da wäre zum Beispiel der Verweis auf einen Spaltennamen der in derselben Abfrage erzeugt wird:<\/p>\n Für diese Abfrage erstellt der Upsizing-Assistent keine SQL Server-Komponente, obwohl die Umsetzung eigentlich trivial ist, denn Sie müssen die Zeile [SumOrder]\/[QtyORder] As Schnitt <\/b>nur durch die eigentlichen Spaltennamen und -Funktionen austauschen:<\/p>\n Dabei ist zu beachten, dass ein Integer geteilt durch einen Integer wieder einen Integer ergibt. Insofern muss die Spalte „Schnitt“ noch in eine Gleitkommazahl konvertiert werden. Ein Garant für Probleme ist bei jedem Datenbanksystem das Datumsformat. Auch der Upsizing-Assistent hat hier so seine Mühe. Access erwartet das Datum im Format #01.03.2008# <\/b>beziehungsweise in der englischen Schreibweise #03.01.2008#<\/b>.<\/p>\n Der SQL Server akzeptiert viele verschiedene Formate, nur die beiden oben genannten eben nicht. Die Ursache für das Problem ist das Kennzeichen #<\/b>. Die beste Lösung ist, dem SQL Server das Datum immer als String im ISO-Format (yyyymmdd<\/b>) zu übergeben.<\/p>\n Dazu kommt noch das Problem mit der teilweise abweichenden SQL-Syntax. In Access wird es dem Anwender leicht gemacht und die DELETE<\/b>-Anweisung der UPDATE<\/b>-Anweisung angepasst. Ob nun beim einfachen Löschen von Datensätzen einer Tabelle oder beim etwas komplexeren Löschen von Datensätzen, für deren Ermittlung zunächst noch weitere Tabellen miteinander verknüpft werden müssen, für den SQL Server enthält die DELETE<\/b>-Anweisung von Access gleich zwei syntaktische Fehler.<\/p>\n Zum einen gibt es im SQL Server kein DELETE * FROM tabelle<\/b>, sondern lediglich ein DELETE FROM tabelle<\/b>, <\/b>und zum anderen wird die Tabellenverknüpfung über INNER JOIN <\/b>in dieser Form nicht unterstützt. Hier kann entweder die SQL Server-Syntax<\/p>\n oder ANSI-SQL verwendet werden:<\/p>\n Last but not least sei noch die Kreuztabellenabfrage erwähnt. Diese wird nicht vom Upsizing-Assistenten umgesetzt, da es in SQL Server keine Kreuztabellenabfragen gibt. In den SQL Server Versionen vor 2005 gibt es nicht mal einen PIVOT-Befehl, denn dieser wurde erst mit dem SQL Server 2005 eingeführt. In der Version 2000 und früher muss die Kreuztabellenabfrage mit einer umständlichen CASE<\/b>-Anweisung umgesetzt werden. Mehr dazu finden Sie in den „Books Online" des SQL Servers unter „Kreuztabellenabfrage“ beziehungsweise „Pivot“. Sie sehen, die Umsetzung der Abfragen in Sichten, gespeicherte Prozeduren beziehungsweise benutzerdefinierte Funktionen ist kein leichtes Unterfangen. Aber der Aufwand lohnt sich, denn er wird mit einer besseren Performance belohnt.<\/p>\n Dies war ein kleiner Einblick in die Vorgehensweise, wie Access die Abfragen an den SQL Server übergibt und wie Sie ermitteln können, welche Datenmengen vom SQL Server an Access übertragen werden. Mit diesen Informationen können Sie nun ein besseres Abfrageverhalten Ihrer Access\/SQL Server-Applikation erzielen. Sie haben dazu zwei Alternativen: Entweder Sie arbeiten weiterhin mit Access-Abfragen und passen diese so an, dass der Abfrageoptimierer diese 1:1 an den SQL Server übergibt, oder aber Sie ersetzen Ihre Access-Abfragen durch die SQL Server-Komponenten Sichten, gespeicherte Prozeduren beziehungsweise benutzerdefinierte Funktionen. Letzteres ist die bessere Alternative, da hier die Ressourcen und Möglichkeiten des SQL Servers genutzt werden und das Netzwerk nur noch mit den relevanten Daten belastet wird. Aber auch hier gibt es einen Haken: In einer MDB können gespeicherte Prozeduren und benutzerdefinierte Funktionen nicht wie Sichten genutzt werden. Mehr zu diesem Thema finden Sie in einem weiteren Beitrag.<\/p>\n","protected":false},"excerpt":{"rendered":" Wussten Sie, dass „Query“ ins Deutsche übersetzt „Abfragen“ heißt Natürlich wussten Sie das. Es ist ja auch die korrekte Bezeichnung, wenn es um Datenbanken geht. Aber wussten Sie auch, dass „Query“ ebenso für „Rückfrage“ und sogar für „Reklamation“ steht Ähnlich ist es mit dem Verb: „to query“ wird als „abfragen“, aber auch als „bezweifeln“ und „in Frage stellen“ verstanden. Nun sollen die Ergebnisse von Access-Abfragen natürlich weder bezweifelt noch in Frage gestellt werden; auch nicht, wenn die Abfragen auf einen SQL Server zugreifen. Aber die Antwortzeiten solcher Abfragen werden Sie in manchen Fällen durchaus bezweifeln. Auch die Vorgehensweise, mit der Access die Daten vom SQL Server anfordert, kann in Frage gestellt werden.<\/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":[662008,66042008,44000029,44000022],"tags":[],"class_list":["post-55000618","post","type-post","status-publish","format-standard","hentry","category-662008","category-66042008","category-Abfragetechnik_und_SQL","category-SQL_Server_und_Co"],"yoast_head":"\n\n\n
\n \n \n (Sicht oder Benutezrdefinierte Funktion auch möglich)<\/pre>\n
![\"pic001.TIF\"](\"..\/fileadmin\/_temp_\/2008_04\/SQLServer-web-images\/pic001_opt.jpeg\")
<\/p>\n![\"pic002.TIF\"](\"..\/fileadmin\/_temp_\/2008_04\/SQLServer-web-images\/pic002_opt.jpeg\")
<\/p>\n![\"pic003.TIF\"](\"..\/fileadmin\/_temp_\/2008_04\/SQLServer-web-images\/pic003_opt.jpeg\")
<\/p>\n![\"pic004.TIF\"](\"..\/fileadmin\/_temp_\/2008_04\/SQLServer-web-images\/pic004_opt.jpeg\")
<\/p>\n\n
Client ist,<\/li>\r\n
Abfragen vs. Sichten<\/h2>\n
Sichten <\/h2>\n
Benutzerdefinierte Funktionen<\/h2>\n
Die Migration<\/h2>\n
SELECT dbo_Products.ProductName,\r\nSum([dbo_Order Details].Quantity) As SumOrder,\r\nCount([dbo_Order Fetails].ProductId) As QtyORder,\r\n[SumOrder]\/[QtyORder] As Schnitt\r\nFROM dbo_Products\r\nINNER JOIN [dbo_Order Details]\r\nON dbo_Products.ProductId\r\n= [dbo_Order Details].ProductId\r\nGROUP BY dbo_Products.ProductName<\/pre>\n
SELECT dbo.Products.ProductName,\r\nSum(dbo.[Order Details].Quantity) As SumOrder,\r\nCount(dbo.[Order Details].ProductId) As QtyORder,\r\nCast(Sum(dbo.[Order Details].Quantity) As float)\r\n\/ Count(dbo.[Order Details].ProductId) As Schnitt FROM dbo.Products\r\nINNER JOIN dbo.[Order Details]\r\nON dbo.Products.ProductId\r\n= dbo.[Order Details].ProductId\r\nGROUP BY dbo.Products.ProductName<\/pre>\n
SELECT dbo.Orders.* FROM dbo.Orders\r\nWHERE dbo.Orders.ShippedDate = '19980506'<\/pre>\n
DELETE [dbo_Order Details].*\r\nFROM [dbo_Order Details]\r\nINNER JOIN dbo_Orders\r\nON [dbo_Order Details].OrderID\r\n= bo_Orders.OrderID\r\nWHERE (((dbo_Orders.ShippedDate) Is Null)\r\nAND ((dbo_Orders.RequiredDate) < #12\/31\/1998#))<\/pre>\n
DELETE FROM dbo.[Order Details]\r\nFROM dbo.[Order Details]\r\nINNER JOIN dbo.Orders\r\nON dbo.[Order Details].OrderId\r\n= dbo.Orders.OrderId\r\nWHERE dbo.Orders.ShippedDate Is Null\r\nAND dbo.Orders.RequiredDate <= '31.12.1998'<\/pre>\n
DELETE FROM dbo.[Order Details]\r\nWHERE dbo.[Order Details].OrderId\r\nIN (\r\nSELECT OrderId\r\nFROM dbo.Orders\r\nWHERE dbo.Orders.ShippedDate Is Null\r\nAND dbo.Orders.RequiredDate <= '31.12.1998')<\/pre>\n
Fazit<\/h2>\n