Freigeben über


Zeichendaten und C-Zeichenfolgen

Eingabeparameter, die auf Zeichendaten mit variabler Länge verweisen (z. B. Spaltennamen, dynamische Parameter und Zeichenfolgen-Attributwerte), weisen einen zugeordneten Längenparameter auf. Wenn die Anwendung Zeichenfolgen mit dem Nullzeichen beendet, wie in C üblich, stellt sie als Argument entweder die Länge in Bytes der Zeichenfolge (nicht einschließlich des Nullzeichens) oder SQL_NTS (Null-terminierte Zeichenfolge) bereit. Ein nicht negatives Längenargument gibt die tatsächliche Länge der zugeordneten Zeichenfolge an. Das Längenargument kann 0 sein, um eine leere Zeichenfolge anzugeben, die sich von einem NULL-Wert unterscheidet. Der negative Wert SQL_NTS weist den Treiber an, die Länge der Zeichenfolge zu bestimmen, indem das Nullterminierungszeichen lokalisiert wird.

Wenn Zeichendaten vom Treiber an die Anwendung zurückgegeben werden, muss der Treiber diese immer mit einem Nullzeichen abschließen. Dadurch erhält die Anwendung die Wahl, ob die Daten als Zeichenfolge oder als Zeichenarray behandelt werden sollen. Wenn der Anwendungspuffer nicht groß genug ist, um alle Zeichen zurückzugeben, kürzt der Treiber die Daten auf die Bytelänge des Puffers minus der Anzahl der Bytes, die für das Nullterminierungszeichen erforderlich sind, nullterminiert die gekürzten Daten und speichert sie im Puffer. Daher müssen Anwendungen immer zusätzlichen Speicherplatz für das Nullendpunktzeichen in Puffern zuweisen, die zum Abrufen von Zeichendaten verwendet werden. Beispielsweise ist ein 51-Byte-Puffer zum Abrufen von 50 Zeichen Daten erforderlich.

Besondere Sorgfalt müssen sowohl die Anwendung als auch der Treiber walten lassen, wenn lange Zeichendaten in Teilen mit SQLPutData oder SQLGetData gesendet oder abgerufen werden. Wenn die Daten als einer Reihe von nullterminierten Zeichenfolgen übergeben werden, müssen die Nullterminierungszeichen für diese Zeichenfolgen entfernt werden, bevor die Daten wieder zusammengesetzt werden können.

Eine Reihe von ODBC-Programmierern haben verwechselte Zeichendaten und C-Zeichenfolgen. Dies ist ein Artefakt der Verwendung der C-Sprache beim Definieren von ODBC-Funktionen. Wenn ein ODBC-Treiber oder eine Anwendung eine andere Sprache verwendet – denken Sie daran, dass ODBC sprachunabhängig ist – ist diese Verwirrung weniger wahrscheinlich.

Wenn C-Zeichenfolgen zum Speichern von Zeichendaten verwendet werden, wird das Nullendpunktzeichen nicht als Teil der Daten betrachtet und wird nicht als Teil der Bytelänge gezählt. Beispielsweise können die Zeichendaten "ABC" als C-Zeichenfolge "ABC\0" oder das Zeichenarray {'A', 'B', 'C'} gespeichert werden. Die Bytelänge der Daten ist 3, unabhängig davon, ob sie als Zeichenfolge oder als Zeichenarray behandelt wird.

Obwohl Anwendungen und Treiber häufig C-Zeichenfolgen (null-beendete Arrays von Zeichen) zum Speichern von Zeichendaten verwenden, ist dies nicht erforderlich. In C können Zeichendaten auch als Array von Zeichen (ohne NULL-Beendigung) behandelt werden und ihre Bytelänge separat im Längen-/Indikatorpuffer übergeben werden.

Da Zeichendaten in einem nicht-nullenbeendeten Array gespeichert werden können und die Bytelänge separat übergeben wird, ist es möglich, Null-Bytes in Zeichendaten einzubetten. Das Verhalten von ODBC-Funktionen in diesem Fall ist jedoch nicht definiert, und es ist treiberspezifisch, ob ein Treiber dies richtig behandelt. Daher sollten interoperable Anwendungen immer Zeichendaten verarbeiten, die eingebettete NULL-Zeichen als Binärdaten enthalten können.