Sdílet prostřednictvím


Zarovnání

Problémy se zarovnáním v aplikaci ODBC se obecně neliší od problémů, které jsou v jakékoli jiné aplikaci. To znamená, že většina aplikací ODBC má jen málo problémů se zarovnáním nebo žádné. Sankce za nerovnání adres se liší podle hardwaru a operačního systému a mohou být menší jako mírné snížení výkonu nebo závažné jako závažná chyba za běhu. Proto by aplikace ODBC a přenosné aplikace ODBC měly být zejména opatrní, aby správně zarovnály data.

Jedním z příkladů, kdy aplikace ODBC narazí na problémy se zarovnáním, je, když přidělují velký blok paměti a sváže různé části této paměti se sloupci v sadě výsledků. K tomu pravděpodobně dojde, když obecná aplikace musí určit tvar sady výsledků za běhu a odpovídajícím způsobem přidělit a svázat paměť.

Předpokládejme například, že aplikace spustí příkaz SELECT zadaný uživatelem a načte výsledky z tohoto příkazu. Vzhledem k tomu, že tvar této sady výsledků není při zápisu programu znám, musí aplikace určit typ každého sloupce po vytvoření sady výsledků a odpovídajícím způsobem svázat paměť. Nejjednodušší způsob, jak to udělat, je přidělit velký blok paměti a svázat různé adresy v tomto bloku s každým sloupcem. Pro přístup k datům ve sloupci aplikace přetypuje paměť vázanou na tento sloupec.

Následující diagram znázorňuje ukázkovou sadu výsledků a způsob, jakým může být blok paměti svázán s použitím výchozího datového typu jazyka C pro každý datový typ SQL. Každý "X" představuje jeden bajt paměti. (Tento příklad ukazuje pouze vyrovnávací paměti dat, které jsou svázány se sloupci. Je to provedeno pro zjednodušení. Ve skutečném kódu musí být také zarovnány vyrovnávací paměti délky a pro ukazatele.)

Výchozí vazba datového typu C na datový typ SQL

Za předpokladu, že vázané adresy jsou uloženy v poli Adresa , aplikace používá následující výrazy pro přístup k paměti vázané na každý sloupec:

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

Všimněte si, že adresy vázané na druhý a třetí sloupec začínají na lichých bajtech a že adresa ve třetím sloupci není dělitelná čtyřmi, což je velikost datového typu SDWORD. Na některých počítačích to nebude problém; v ostatních, to způsobí mírné snížení výkonu; u ostatních způsobí závažnou chybu za běhu. Lepším řešením by bylo zarovnat každou ohraničenou adresu na její přirozenou hranici zarovnání. Za předpokladu, že je to 1 pro UCHAR, 2 pro SWORD a 4 pro SDWORD, to by dal výsledek zobrazený na následujícím obrázku, kde "X" představuje bajt paměti, který se používá, a "O" představuje bajt paměti, který se nepoužívá.

Vazba podle hranice přirozeného zarovnání

I když toto řešení nepoužívá veškerou paměť aplikace, nenarazí na žádné problémy se zarovnáním. Implementace tohoto řešení bohužel vyžaduje poměrně velké množství kódu, protože každý sloupec musí být zarovnaný jednotlivě podle svého typu. Jednodušším řešením je zarovnat všechny sloupce na velikosti největší hranice zarovnání, což je 4 v příkladu uvedeném na následujícím obrázku.

Vazba podle největší hranice zarovnání

I když toto řešení ponechá větší díry, kód, který ho implementuje, je poměrně jednoduchý a rychlý. Ve většině případů se tím vyrovnají náklady vynaložené na nevyužitou paměť. Příklad, který používá tuto metodu, viz Using SQLBindCol.