Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
gäller för:
SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse Analytics
En ODBC-applikation har tre alternativ för att hämta resultatdata.
Det första alternativet baseras på SQLBindCol. Innan resultatmängden hämtas använder applikationen SQLBindCol för att binda varje kolumn i resultatmängden till en programvariabel. Efter att kolumnerna har bundits överför drivrutinen data från den aktuella raden till de variabler som är bundna till resultatuppsättningens kolumner varje gång applikationen anropar SQLFetch eller SQLFetchScroll. Drivrutinen hanterar datakonverteringar om resultatuppsättningskolumnen och programvariabeln har olika datatyper. Om applikationen har SQL_ATTR_ROW_ARRAY_SIZE mängd större än 1 kan den binda resultatkolumner till arrayer av variabler, vilka alla fylls vid varje anrop till SQLFetchScroll.
Det andra alternativet baseras på SQLGetData. Applikationen använder inte SQLBindCol för att binda resultatuppsättningskolumner till programvariabler. Efter varje anrop till SQLFetch anropar applikationen SQLGetData en gång för varje kolumn i resultatuppsättningen. SQLGetData instruerar drivrutinen att överföra data från en specifik resultatuppsättningskolumn till en specifik programvariabel och specificerar datatyperna för kolumnen och variabeln. Detta gör att drivrutinen kan konvertera data om resultatkolumnen och programvariabeln har olika datatyper. Text-, ntext- och bildkolumner är vanligtvis för stora för att rymmas i en programvariabel men kan ändå hämtas med SQLGetData. Om text-, ntext- eller bilddata i resultatkolumnen är större än programvariabeln, returnerar SQLGetData SQL_SUCCESS_WITH_INFO och SQLSTATE 01004 (strängdata, högertrunkerad). Successiva anrop till SQLGetData returnerar successiva bitar av text - eller bilddata . När datan är slut returnerar SQLGetData SQL_SUCCESS. Varje hämtning returnerar en uppsättning rader, eller raduppsättning, om SQL_ATTR_ROW_ARRAY_SIZE är större än 1. Innan du använder SQLGetData måste du först använda SQLSetPos för att specificera en specifik rad inom raduppsättningen som den aktuella raden.
Det tredje alternativet är att använda en blandning av SQLBindCol och SQLGetData. En applikation skulle till exempel kunna binda de första tio kolumnerna i en resultatmängd och sedan, vid varje hämtning, anropa SQLGetData tre gånger för att hämta data från tre obundna kolumner. Detta används vanligtvis när en resultatmängd innehåller en eller flera text - eller bildkolumner .
Beroende på vilka kursoralternativ som är inställda för resultatuppsättningen kan en applikation också använda rullningsalternativen i SQLFetchScroll för att bläddra runt resultatuppsättningen.
Överdriven användning av SQLBindCol för att binda en resultatuppsättningskolumn till en programvariabel är kostsam eftersom SQLBindCol får en ODBC-drivrutin att allokera minne. När du binder en resultatkolumn till en variabel förblir den bindningen i kraft tills du antingen anropar SQLFreeHandle för att frigöra satshandtaget eller anropar SQLFreeStmt med fOption satt till SQL_UNBIND. Bindningarna upphävs inte automatiskt när satsen är klar.
Denna logik gör att du effektivt kan köra samma SELECT-sats flera gånger med olika parametrar. Eftersom resultatuppsättningen behåller samma struktur kan du binda resultatuppsättningen en gång, bearbeta alla SELECT-satser och sedan anropa SQLFreeStmt med fOption satt till SQL_UNBIND efter senaste exekveringen. Du bör inte anropa SQLBindCol för att binda kolumnerna i en resultatuppsättning utan att först anropa SQLFreeStmt med fOption satt på SQL_UNBIND för att frigöra tidigare bindningar.
När du använder SQLBindCol kan du antingen binda rad eller kolumn. Radbindning går något snabbare än kolumnbundning.
Du kan använda SQLGetData för att hämta data kolumn för kolumn istället för att binda resultatuppsättningskolumner med SQLBindCol. Om en resultatmängd bara innehåller några få rader är det snabbare att använda SQLGetData istället för SQLBindCol ; annars ger SQLBindCol bäst prestanda. Om du inte alltid lägger datan i samma uppsättning variabler bör du använda SQLGetData istället för att ständigt binda om. Du kan bara använda SQLGetData på kolumner som finns i urvalslistan efter att alla kolumner har bundits med SQLBindCol. Kolumnen måste också visas efter eventuella kolumner där du redan har använt SQLGetData.
ODBC-funktionerna som hanterar att flytta data in eller ut ur programvariabler, såsom SQLGetData, SQLBindCol och SQLBindParameter, stödjer implicit datatypkonvertering. Till exempel, om en applikation binder en heltalskolumn till en teckensträngsvariabel, konverterar drivrutinen automatiskt datan från heltal till tecken innan den placerar den i programvariabeln.
Datakonvertering i applikationer bör minimeras. Om inte datakonvertering krävs för bearbetningen som görs av applikationen, bör applikationer binda kolumner och parametrar till programvariabler av samma datatyp. Om datan måste konverteras från en typ till en annan är det dock mer effektivt att låta drivrutinen göra konverteringen än att göra det i applikationen. SQL Server Native Client ODBC-drivrutinen överför normalt bara data direkt från nätverksbuffertarna till applikationens variabler. Att begära att drivrutinen gör datakonvertering tvingar drivrutinen att buffra datan och använda CPU-cykler för att konvertera datan.
Programvariabler bör vara tillräckligt stora för att hålla data som överförs från en kolumn, förutom text-, ntext- och bilddata . Om en applikation försöker hämta resultatdata och placera den i en variabel som är för liten för att lagra den, genererar drivrutinen en varning. Detta tvingar drivrutinen att allokera minne för meddelandet, och både drivrutinen och applikationen måste spendera CPU-cykler på att bearbeta meddelandet och hantera fel. Applikationen bör antingen tilldela en variabel som är tillräckligt stor för att hålla den data som hämtas eller använda SUBSTRING-funktionen i select-listan för att minska kolumnens storlek i resultatuppsättningen.
Man måste vara försiktig vid användning av SQL_C_DEFAULT för att specificera typen av C-variabeln. SQL_C_DEFAULT specificerar att typen av C-variabeln matchar SQL-datatypen för kolumnen eller parametern. Om SQL_C_DEFAULT anges för en ntext-, nchar- eller nvarchar-kolumn , returneras Unicode-data till applikationen. Detta kan orsaka olika problem om applikationen inte har programmerats för att hantera Unicode-data. Samma typer av problem kan uppstå med unikidentifieraren (SQL_GUID) datatypen.
text-, ntext- och bilddata är vanligtvis för stora för att rymmas i en enda programvariabel och behandlas vanligtvis med SQLGetData istället för SQLBindCol. När servermarkörer används är SQL Server Native Client ODBC-drivrutin optimerad för att inte överföra data för obunden text, ntext eller bildkolumner när raden hämtas. Text-, ntext- eller bilddata hämtas faktiskt inte från servern förrän applikationen skickar SQLGetData för kolumnen.
Denna optimering kan tillämpas på applikationer så att ingen text-, ntext- eller bilddata visas medan användaren scrollar upp och ner på en markör. Efter att användaren valt en rad kan applikationen anropa SQLGetData för att hämta text-, ntext- eller bilddata . Detta sparar överföring av text-, ntext- eller bilddata för rader som användaren inte väljer och kan spara överföring av mycket stora datamängder.