Teckendata och C-strängar

Indataparametrar som refererar till teckendata med variabel längd (till exempel kolumnnamn, dynamiska parametrar och strängattributvärden) har en associerad längdparameter. Om programmet avslutar strängar med null-tecknet, vilket är typiskt i C, ger det som argument antingen längden i byte av strängen (exklusive null-terminator) eller SQL_NTS (Null-Terminated String). Ett argument för icke-negativ längd anger den faktiska längden på den associerade strängen. Argumentet längd kan vara 0 för att ange en sträng med noll längd, vilket skiljer sig från ett NULL-värde. Det negativa värdet SQL_NTS instruerar drivrutinen att fastställa längden på strängen genom att hitta null-avslutningstecknet.

När teckendata returneras från drivrutinen till applikationen, måste drivrutinen alltid avsluta den med en null. Detta ger programmet möjlighet att välja om data ska hanteras som en sträng eller en teckenmatris. Om applikationsbufferten inte är tillräckligt stor för att returnera all teckendata trunkerar drivrutinen den till buffertens bytelängd minus det antal byte som behövs för noll-avslutningen, avslutar de trunkerade data med null och lagrar dem i bufferten. Därför måste program alltid allokera extra utrymme för null-avslutningstecknet i buffertar som används för att hämta teckendata. Till exempel krävs en buffert på 51 byte för att hämta 50 tecken data.

Du måste vara särskilt försiktig med både programmet och drivrutinen när du skickar eller hämtar långa teckendata i delar med SQLPutData eller SQLGetData. Om data skickas som en serie null-avslutade strängar måste null-avslutningstecken på dessa strängar tas bort innan data kan sättas ihop igen.

Ett antal ODBC-programmerare har förvirrade teckendata och C-strängar. Att detta har inträffat är en artefakt av att använda C-språket när du definierar ODBC-funktioner. Om en ODBC-drivrutin eller ett annat program använder ett annat språk – kom ihåg att ODBC är språkoberoende – är det mindre troligt att den här förvirringen uppstår.

När C-strängar används för att lagra teckendata anses inte null-avslutningstecknet vara en del av data och räknas inte som en del av bytelängden. Till exempel kan teckendata "ABC" lagras som C-strängen "ABC\0" eller teckenmatrisen {'A', 'B', 'C'}. Bytelängden för data är 3, oavsett om de behandlas som en sträng eller en teckenmatris.

Även om program och drivrutiner ofta använder C-strängar (null-avslutade matriser med tecken) för att lagra teckendata, finns det inget krav på att göra detta. I C kan teckendata också behandlas som en matris med tecken (utan null-avslutning) och dess bytelängd skickas separat i längden/indikatorbufferten.

Eftersom teckendata kan lagras i en icke-null-avslutad matris och dess bytelängd skickas separat, är det möjligt att bädda in null-tecken i teckendata. Beteendet för ODBC-funktioner i det här fallet är dock odefinierat och det är drivrutinsspecifikt om en drivrutin hanterar detta korrekt. Därför bör samverkande program alltid hantera teckendata som kan innehålla inbäddade null-tecken som binära data.