Simulera positionerade uppdaterings- och raderingssatser

Om datakällan inte stöder positionerade uppdaterings- och borttagningsuttryck kan drivrutinen simulera dessa. Till exempel simulerar ODBC-markörbiblioteket positionerade uppdaterings- och borttagningsinstruktioner. Den allmänna strategin för att simulera positionerade uppdaterings- och borttagningsinstruktioner är att konvertera positionerade instruktioner till sökta. Detta görs genom att ersätta WHERE CURRENT OF-satsen med en genomsökt WHERE-sats som identifierar den aktuella raden.

Till exempel eftersom kolumnen CustID unikt identifierar varje rad i tabellen Kunder, den positionerade borttagningssatsen

DELETE FROM Customers WHERE CURRENT OF CustCursor  

kan konverteras till

DELETE FROM Customers WHERE (CustID = ?)  

Drivrutinen kan använda en av följande radidentifierare i WHERE-villkoret:

• Kolumner vars värden används för att identifiera varje rad i tabellen unikt. Om du till exempel anropar SQLSpecialColumns med SQL_BEST_ROWID returneras den optimala kolumnen eller uppsättningen kolumner som tjänar det här syftet.

• Pseudokolumner, som tillhandahålls av vissa datakällor, för att unikt identifiera varje rad. Dessa kan också hämtas genom att anropa SQLSpecialColumns.

• Ett unikt index, om det är tillgängligt.

• Alla kolumner i resultatuppsättningen.

Exakt vilka kolumner en drivrutin ska använda i WHERE-satsen som den konstruerar beror på drivrutinen. För vissa datakällor kan det vara kostsamt att fastställa en radidentifierare. Det går dock snabbare att köra och garanterar att ett simulerat uttryck uppdaterar eller tar bort högst en rad. Beroende på funktionerna i den underliggande DBMS kan det vara dyrt att använda en radidentifierare. Det går dock snabbare att köra och garanterar att en simulerad instruktion endast uppdaterar eller tar bort en rad. Alternativet att använda alla kolumner i resultatuppsättningen är vanligtvis mycket enklare att konfigurera. Det går dock långsammare att köra, och om kolumnerna inte identifierar en rad unikt kan det leda till att rader oavsiktligt uppdateras eller tas bort, särskilt när urvalslistan för resultatuppsättningen inte innehåller alla kolumner som finns i den underliggande tabellen.

Beroende på vilka av de föregående strategierna som drivrutinen stöder kan ett program välja vilken strategi det vill att drivrutinen ska använda med SQL_ATTR_SIMULATE_CURSOR-instruktionsattributet. Även om det kan verka konstigt att ett program oavsiktligt uppdaterar eller tar bort en rad, kan programmet ta bort den här risken genom att se till att kolumnerna i resultatuppsättningen unikt identifierar varje rad i resultatuppsättningen. Detta sparar föraren ansträngningen att behöva göra detta.

Om drivrutinen väljer att använda en radidentifierare fångar den upp instruktionen SELECT FOR UPDATE som skapar resultatuppsättningen. Om kolumnerna i urvalslistan inte identifierar en rad på ett effektivt sätt lägger drivrutinen till de kolumner som behövs i slutet av urvalslistan. Vissa datakällor har en enda kolumn som alltid unikt identifierar en rad, till exempel ROWID-kolumnen i Oracle. Om en sådan kolumn är tillgänglig använder drivrutinen detta. Annars anropar drivrutinen SQLSpecialColumns för varje tabell i FROM-satsen för att hämta en lista över de kolumner som unikt identifierar varje rad. En vanlig begränsning som följer av den här tekniken är att markörsimuleringen misslyckas om det finns mer än en tabell i FROM-satsen .

Oavsett hur drivrutinen identifierar rader tas satsen FOR UPDATE OF vanligtvis bort från SELECT FOR UPDATE-instruktionen innan den skickas till datakällan. FOR UPDATE OF-satsen används endast med positionerade uppdaterings- och raderingsinstruktioner. Datakällor som inte stöder positionerade uppdaterings- och borttagningsinstruktioner stöder vanligtvis inte det.

När applikationen skickar en positionerad uppdaterings- eller borttagningsinstruktion för att köras, ersätter drivrutinen WHERE CURRENT OF-satsen med en WHERE-sats som innehåller radidentifieraren. Värdena för dessa kolumner hämtas från en cache som underhålls av drivrutinen för varje kolumn som används i WHERE-satsen . När drivrutinen har ersatt WHERE-satsen skickar den -instruktionen till datakällan för körning.

Anta till exempel att programmet skickar följande instruktion för att skapa en resultatuppsättning:

SELECT Name, Address, Phone FROM Customers FOR UPDATE OF Phone, Address  

Om programmet har angett SQL_ATTR_SIMULATE_CURSOR för att begära en garanti för unikhet och om datakällan inte tillhandahåller en pseudokolumn som alltid unikt identifierar en rad, anropar drivrutinen SQLSpecialColumns för tabellen Kunder, upptäcker att CustID är nyckeln till tabellen Kunder och lägger till den i urvalslistan. och tar bort FOR UPDATE OF-satsen :

SELECT Name, Address, Phone, CustID FROM Customers  

Om programmet inte har begärt en garanti för unikhet, tar drivrutinen endast bort satsen FOR UPDATE OF :

SELECT Name, Address, Phone FROM Customers  

Anta att programmet rullar igenom resultatsatsen och skickar följande positionerad uppdateringsfråga för körning, där Cust är markörens namn över resultatsatsen.

UPDATE Customers SET Address = ?, Phone = ? WHERE CURRENT OF Cust  

Om programmet inte har begärt någon unik garanti ersätter drivrutinen WHERE-satsen och binder CustID-parametern till variabeln i cacheminnet:

UPDATE Customers SET Address = ?, Phone = ? WHERE (CustID = ?)  

Om programmet inte har begärt någon unik garanti ersätter drivrutinen WHERE-satsen och binder parametrarna Namn, Adress och Telefon i den här satsen till variablerna i cacheminnet:

UPDATE Customers SET Address = ?, Phone = ?  
   WHERE (Name = ?) AND (Address = ?) AND (Phone = ?)