Betrieb parameterisierter Befehle

Wenn Sie mit einem großen untergeordneten Recordset-arbeiten, das besonders im Vergleich zur Größe des übergeordneten Recordset-groß ist, aber nur auf einige Kapitel des untergeordneten Recordsets zugreifen müssen, kann es effizienter sein, einen parametrisierten Befehl zu verwenden.

Ein nicht parametrisierten Befehl ruft sowohl das gesamte übergeordnete als auch das untergeordnete element Recordsetsab, fügt eine Kapitelspalte an das übergeordnete Element an und weist dann für jede übergeordnete Zeile einen Verweis auf das zugehörige untergeordnete Kapitel zu.

Ein parametrisierter Befehl ruft das gesamte übergeordnete Recordset-ab, ruft jedoch nur das Kapitel Recordset ab, wenn auf die Kapitelspalte zugegriffen wird. Dieser Unterschied bei der Abrufstrategie kann zu erheblichen Leistungsvorteilen führen.

Sie können beispielsweise Folgendes angeben:

SHAPE {SELECT * FROM customer}   
   APPEND ({SELECT * FROM orders WHERE cust_id = ?}   
   RELATE cust_id TO PARAMETER 0)  

Die übergeordneten und untergeordneten Tabellen weisen einen gemeinsamen Spaltennamen auf, cust_id. Der untergeordnete Befehl hat einen Platzhalter "?", auf den die RELATE-Klausel verweist (das heißt "...PARAMETER 0").

Anmerkung

Die PARAMETER-Klausel bezieht sich ausschließlich auf die Shape-Befehlssyntax. Es ist weder dem ADO Parameter-Objekt noch der Parameters-Auflistung zugeordnet.

Wenn der parametrisierte Shape-Befehl ausgeführt wird, tritt Folgendes auf:

1. Der übergeordnete Befehl wird ausgeführt und gibt ein übergeordnetes Recordset aus der Tabelle "Customers" zurück.

2. Eine Kapitelspalte wird an das übergeordnete Recordsetangefügt.

3. Wenn auf die Kapitelspalte einer übergeordneten Zeile zugegriffen wird, wird der untergeordnete Befehl unter Verwendung des Werts von customer.cust_id als Parameterwert ausgeführt.

4. Alle Zeilen im in Schritt 3 erstellten Datenanbieter-Rowset werden verwendet, um das untergeordnete Recordsetzu füllen. In diesem Beispiel ist dies alle Zeilen in der Tabelle "Bestellungen", in der die cust_id dem Wert von customer.cust_id entspricht. Standardmäßig wird das untergeordnete Recordsets auf dem Client zwischengespeichert, bis alle Verweise auf das übergeordnete Recordset- freigegeben werden. Um dieses Verhalten zu ändern, legen Sie das Recordsetdynamische EigenschaftCache Child Rows auf "False"fest.

5. Ein Verweis auf die abgerufenen untergeordneten Zeilen (d. h. das Kapitel des untergeordneten Recordset) wird in der Kapitelspalte der aktuellen Zeile des übergeordneten Recordsetplatziert.

6. Die Schritte 3 bis 5 werden wiederholt, wenn auf die Kapitelspalte einer anderen Zeile zugegriffen wird.

Die untergeordneten Zeilen zwischenspeichern dynamische Eigenschaft ist standardmäßig auf "True" festgelegt. Das Zwischenspeicherungsverhalten hängt von den Parameterwerten der Abfrage ab. In einer Abfrage mit einem einzelnen Parameter wird das untergeordnete 'Child' Recordset für einen bestimmten Parameterwert zwischengespeichert, solange Anfragen für ein solches Child mit diesem Wert gestellt werden. Der folgende Code veranschaulicht folgendes:

SCmd = "SHAPE {select * from customer} " & _  
         "APPEND({select * from orders where cust_id = ?} " & _  
         "RELATE cust_id TO PARAMETER 0) AS chpCustOrder"  
Rst1.Open sCmd, Cnn1  
Set RstChild = Rst1("chpCustOrder").Value  
Rst1.MoveNext      ' Next cust_id passed to Param 0, & new rs fetched   
                   ' into RstChild.  
Rst1.MovePrevious  ' RstChild now holds cached rs, saving round trip.  

In einer Abfrage mit mindestens zwei Parametern wird ein zwischengespeichertes untergeordnetes Element nur verwendet, wenn alle Parameterwerte mit den zwischengespeicherten Werten übereinstimmen.

Parametrisierte Befehle und komplexe Übergeordnete und Untergeordnete Beziehungen

Zusätzlich zur Verwendung parametrisierter Befehle zur Verbesserung der Leistung einer Equi-Join-Typhierarchie können solche Befehle auch genutzt werden, um komplexere Beziehungen zwischen Eltern- und Kindelementen zu unterstützen. Betrachten Sie beispielsweise eine Little League-Datenbank mit zwei Tabellen: eine bestehend aus den Teams (team_id, team_name) und die andere aus den Spielen (Datum, home_team, visiting_team).

Bei der Verwendung einer nicht-parametrisierten Hierarchie gibt es keine Möglichkeit, die Team- und Spieltabellen so zu verbinden, dass das untergeordnete Recordset für jedes Team den vollständigen Zeitplan enthält. Sie können Kapitel erstellen, die den Hauszeitplan oder den Straßenplan enthalten, aber nicht beides. Dies liegt daran, dass die RELATE-Klausel Sie auf Beziehungen zwischen übergeordneten und untergeordneten Elementen in der Form (pc1=cc1) UND (pc2=pc2) beschränkt. Wenn Ihr Befehl also "RELATE team_id TO home_team, team_id TO visiting_team" enthielt, würden Sie nur Spiele erhalten, bei denen ein Team gegen sich selbst spielt. Was Sie möchten, ist "(team_id=home_team) OR (team_id=visiting_team)", aber der Shape-Anbieter unterstützt die OR-Klausel nicht.

Um das gewünschte Ergebnis zu erhalten, können Sie einen parametrisierten Befehl verwenden. Zum Beispiel:

SHAPE {SELECT * FROM teams}   
APPEND ({SELECT * FROM games WHERE home_team = ? OR visiting_team = ?}   
        RELATE team_id TO PARAMETER 0,   
               team_id TO PARAMETER 1)   

In diesem Beispiel wird die größere Flexibilität der SQL WHERE-Klausel ausgenutzt, um das benötigte Ergebnis zu erhalten.

Anmerkung

Bei der Verwendung von WHERE-Klauseln dürfen Parameter nicht die SQL-Datentypen text, ntext und image verwenden, da sonst ein Fehler auftritt, der die folgende Beschreibung enthält: Invalid operator for data type.

Siehe auch

Datenstrukturierungsbeispiel
formale Shape-Grammatik
Shape-Befehle im Allgemeinen