Problème lors de l'utilisation de sqlldr.exe avec des valeurs NCLOB lorsque des caractères Unicode non compris dans la plage de codes ASCII sont utilisés

Question

Lorsque nous utilisons sqlldr pour remplir une colonne NCLOB avec une valeur de texte d'un fichier lob et que le caractère ne se trouve pas dans la plage de codes ASCII bombes.

---

sections qui semblent pertinents à partir du fichier journal:

 
EXTENSIONDATA      DERIVED *****   VARCHARC    
    Maximum field length is -2147483639 
    Static LOBFILE. Filename is C:\Temp\fb6b023e-7bac-4c93-814a-c7adecc11ad5.lob 
    Character Set UTF8 specified for all input. 

SQL*Loader-462: error inserting LOB into column EXTENSIONDATA, row 106, table ENTITYEXTENSIONDATA 
secondary data file for LOB is C:\Temp\fb6b023e-7bac-4c93-814a-c7adecc11ad5.lob 
file offset for beginning of lob is 18393 
SQL*Loader-645: error converting character length field to a number 

---

fichier de contrôle a

 
LOAD DATA 
CHARACTERSET UTF8 
INFILE "C:\Temp\eb5e656c-94d1-4a0e-99be-3df8fa0d4461.bcp" 
BADFILE "C:\Temp\eb5e656c-94d1-4a0e-99be-3df8fa0d4461.bad" 
APPEND 
INTO TABLE EntityExtensionData REENABLE 
FIELDS TERMINATED BY '||' 
TRAILING NULLCOLS 
(EntityExtensionDataId,EntityId,ExtensionData LOBFILE(CONSTANT 'C:\Temp\eb5e656c-94d1-4a0e-99be-3df8fa0d4461.lob') VARCHARC(10,2147483647)) 

Answer 1

Quand je déterminait la longueur de la valeur de la valeur lob pour le placer Dans l'enregistrement du fichier lob, j'utilisais string.Length. Évidemment, quand c'était un caractère multi-octets ce serait la mauvaise taille en octets. Le correctif consistait simplement à le modifier pour utiliser Encoding.UTF8.GetByteCount() pour obtenir la taille correcte.