Justering

Justeringsproblemen i ett ODBC-program skiljer sig vanligtvis inte från andra program. De flesta ODBC-program har alltså få eller inga problem med anpassningen. Straffen för att inte justera adresser varierar med maskinvaran och operativsystemet och kan vara lika små som en liten prestandapåföljd eller så stor som ett allvarligt körningsfel. Därför bör ODBC-program och portabla ODBC-program i synnerhet vara noga med att justera data korrekt.

Ett exempel på när ODBC-program stöter på justeringsproblem är när de allokerar ett stort minnesblock och binder olika delar av minnet till kolumnerna i en resultatuppsättning. Detta inträffar troligen när ett allmänt program måste fastställa formen på en resultatuppsättning vid körning och allokera och binda minne i enlighet med detta.

Anta till exempel att ett program kör en SELECT-instruktion som angetts av användaren och hämtar resultatet från den här instruktionen. Eftersom formen på den här resultatuppsättningen inte är känd när programmet skrivs måste programmet fastställa typen av varje kolumn efter att resultatuppsättningen har skapats och binda minne därefter. Det enklaste sättet att göra detta är att allokera ett stort minnesblock och binda olika adresser i blocket till varje kolumn. För att komma åt data i en kolumn omvandlar programmet minnet som är bundet till den kolumnen.

Följande diagram visar en exempelresultatuppsättning och hur ett minnesblock kan bindas till den med C-standarddatatypen för varje SQL-datatyp. Varje "X" representerar en enda byte minne. (I det här exemplet visas endast de databuffertar som är bundna till kolumnerna. Detta görs för enkelhetens skull. I den faktiska koden måste även längden/indikatorbuffertarna justeras.)

Förutsatt att de bundna adresserna lagras i matrisen Adress använder programmet följande uttryck för att komma åt minnet som är bundet till varje kolumn:

(SQLCHAR *)       Address[0]  
(SQLSMALLINT *)   Address[1]  
(SQLINTEGER *)    Address[2]  

Observera att adresserna som är bundna till den andra och tredje kolumnerna börjar på udda numrerade byte och att adressen som är bunden till den tredje kolumnen inte är delbar med fyra, vilket är storleken på ett SDWORD. På vissa datorer är detta inte ett problem. På andra kommer det att orsaka en liten försämring av prestandan. På ytterligare andra kommer det att orsaka ett allvarligt körningsfel. En bättre lösning skulle vara att justera varje bunden adress på dess naturliga justeringsgräns. Förutsatt att detta är 1 för en UCHAR, 2 för ett SVÄRD och 4 för ett SDWORD, skulle detta ge resultatet som visas i följande bild, där ett "X" representerar en byte minne som används och ett "O" representerar en byte minne som inte används.

Även om den här lösningen inte använder hela programmets minne, uppstår inga justeringsproblem. Tyvärr krävs det en hel del kod för att implementera den här lösningen, eftersom varje kolumn måste justeras individuellt enligt dess typ. En enklare lösning är att justera alla kolumner efter storleken på den största justeringsgränsen, vilket är 4 i exemplet som visas i följande bild.

Även om den här lösningen lämnar större hål är koden för att implementera den relativt enkel och snabb. I de flesta fall kompenserar detta förlusten i form av oanvänt minne. Ett exempel som använder den här metoden finns i Använda SQLBindCol.