Adathossz, puffer hossza és csonkolás

Az adathossz az adatok bájthossza, mivel azokat az alkalmazás adatpufferében tárolnák, nem pedig az adatforrásban. Ez a különbség azért fontos, mert az adatokat gyakran különböző típusok tárolják az adatpufferben, mint az adatforrásban. Így az adatforrásba küldött adatok esetében ez az adatok bájthossza az adatforrás típusára való átalakítás előtt. Az adatforrásból lekérendő adatok esetében ez az adatok bájthossza az adatpuffer típusának konvertálása után és a csonkolás előtt.

Rögzített hosszúságú adatok, például egész szám vagy dátumstruktúra esetén az adatok bájthossza mindig az adattípus mérete. Az alkalmazások általában olyan adatpuffert foglalnak le, amely az adattípus mérete. Ha az alkalmazás kisebb puffert foglal le, a következmények nem lesznek meghatározva, mert az illesztőprogram feltételezi, hogy az adatpuffer az adattípus mérete, és nem csonkítja az adatokat, hogy kisebb pufferbe illeszkedjenek. Ha az alkalmazás nagyobb puffert foglal le, a rendszer soha nem használja fel a további területet.

Változó hosszúságú adatok, például karakterek vagy bináris adatok esetében fontos felismerni, hogy az adatok bájthossza eltér a puffer bájthosszától, és gyakran eltér a puffer bájthosszától. A két hossz relációját a Pufferek szakaszban ismertetjük . Ha az adatok bájthossza nagyobb, mint a puffer bájthossza, az illesztőprogram csonkolja a lekért adatokat a puffer bájthosszára, és visszaküldi az SQL_SUCCESS_WITH_INFO-t az SQLSTATE 01004 (Csonkolt adatok) kóddal. A visszaadott bájthossz azonban a csonkolatlan adatok hossza.

Tegyük fel például, hogy egy alkalmazás 50 bájtot foglal le egy bináris adatpufferhez. Ha az illesztő 10 bájt bináris adatot ad vissza, a pufferben lévő 10 bájtot adja vissza. Az adatok bájthossza 10, a puffer bájthossza pedig 50. Ha az illesztőnek 60 bájt bináris adatot kell visszaadnia, az adatokat 50 bájtra csonkolja, a pufferben lévő bájtokat adja vissza, és SQL_SUCCESS_WITH_INFO ad vissza. Az adatok bájthossza 60 (a csonkolás előtti hossz), a puffer bájthossza pedig még mindig 50.

A rendszer minden csonkolt oszlophoz létrehoz egy diagnosztikai rekordot. Mivel az illesztőprogramnak időre van szükség ezeknek a rekordoknak a létrehozásához és az alkalmazás feldolgozásához, a csonkolás csökkentheti a teljesítményt. Az alkalmazások általában elkerülhetik ezt a problémát elég nagy pufferek kiosztásával, bár ez hosszú adatok használata esetén nem feltétlenül lehetséges. Ha az adatok csonkolása történik, az alkalmazás néha nagyobb puffert foglal le, és újra betölti az adatokat; ez nem minden esetben igaz. Ha csonkolás történik az SQLGetData felé irányuló hívások során, az alkalmazásnak nem kell meghívnia az SQLGetData-t a már visszaadott adatokhoz; további információt a Hosszú adatok lekérése című témakörben talál.