Comme on m'a demandé dans les commentaires comment je résoudrais cela, je vais l'écrire en réponse.
Être dans une telle situation suggère des erreurs dans la conception de l'application. Considérez ce que cela signifie.
Vous avez un texte dont vous ne pouvez pas préciser la longueur à l'avance, et qui peut être extrêmement long (jusqu'à 64k), dont vous souhaitez conserver l'unicité. Imaginez une telle quantité de données divisées en clés distinctes et composant un index composite pour générer l'unicité. C'est ce que vous essayez de faire. Pour les nombres entiers, il s'agirait d'un index de 16 000 nombres entiers, joints dans un index composite.
Considérez en outre que les champs de type CHARACTER (CHAR, VARCHAR, TEXT) sous-tendent l'interprétation par encodage, ce qui complique encore le problème.
Je recommanderais fortement de diviser les données d'une manière ou d'une autre. Cela libère non seulement le SGBD de l'incorporation de blocs de caractères de longueur variable, mais peut également donner la possibilité de générer des clés composites sur des parties des données. Peut-être pourriez-vous même trouver une meilleure solution de stockage pour vos données.
Si vous avez des questions, je vous suggère de publier la structure de la table et/ou de la base de données et d'expliquer quelles données logiques contient le champ TEXTE, et pourquoi vous pensez qu'il devrait être unique.
