Longueur des données, longueur de la mémoire tampon et troncation
La longueur des données est la longueur d’octet des données, car elles sont stockées dans la mémoire tampon de données de l’application, et non pas dans la source de données. Cette distinction est importante, car les données sont souvent stockées dans différents types dans la mémoire tampon de données que dans la source de données. Par conséquent, pour les données envoyées à la source de données, il s’agit de la longueur d’octet des données avant la conversion vers le type de la source de données. Pour les données récupérées à partir de la source de données, il s’agit de la longueur d’octet des données après la conversion vers le type de la mémoire tampon de données et avant toute troncation.
Pour les données de longueur fixe, telles qu’un entier ou une structure de date, la longueur d’octet des données est toujours la taille du type de données. En général, les applications allouent une mémoire tampon de données qui correspond à la taille du type de données. Si l’application alloue une mémoire tampon plus petite, les conséquences ne sont pas définies, car le pilote suppose que la mémoire tampon de données est la taille du type de données et ne tronque pas les données pour s’adapter à une mémoire tampon plus petite. Si l’application alloue une mémoire tampon plus grande, l’espace supplémentaire n’est jamais utilisé.
Pour les données de longueur variable, telles que les données caractères ou binaires, il est important de reconnaître que la longueur d’octets des données est séparée et souvent différente de la longueur d’octets de la mémoire tampon. La relation de ces deux longueurs est décrite dans la section Mémoires tampons . Si la longueur d’octets des données est supérieure à la longueur d’octet de la mémoire tampon, le pilote tronque les données extraites à la longueur d’octet de la mémoire tampon et retourne SQL_SUCCESS_WITH_INFO avec SQLSTATE 01004 (tronqué des données). Toutefois, la longueur d’octet retournée est la longueur des données non chiffrées.
Par exemple, supposons qu’une application alloue 50 octets pour une mémoire tampon de données binaire. Si le pilote a 10 octets de données binaires à retourner, il retourne ces 10 octets dans la mémoire tampon. La longueur d’octet des données est 10, et la longueur d’octet de la mémoire tampon est de 50. Si le pilote a 60 octets de données binaires à retourner, il tronque les données à 50 octets, retourne ces octets dans la mémoire tampon et retourne SQL_SUCCESS_WITH_INFO. La longueur d’octet des données est 60 (la longueur avant la troncation) et la longueur d’octets de la mémoire tampon est toujours de 50.
Un enregistrement de diagnostic est créé pour chaque colonne tronquée. Étant donné qu’il faut du temps pour que le pilote crée ces enregistrements et que l’application les traite, la troncation peut dégrader les performances. En règle générale, une application peut éviter ce problème en allouant suffisamment de mémoires tampons, bien que cela ne soit peut-être pas possible lors de l’utilisation de données longues. Lorsque la troncation des données se produit, l’application peut parfois allouer une mémoire tampon plus grande et refetcher les données ; cela n’est pas vrai dans tous les cas. Si la troncation se produit lors de l’obtention de données avec des appels à SQLGetData, l’application n’a pas besoin d’appeler SQLGetData pour les données qui ont déjà été retournées. Pour plus d’informations, consultez Obtention de données longues.