Discussion :

[Tylert]

Bonjour,

Je cherche à savoir si certains champs de ma base de données contiennent des caractères spéciaux non-latins mais UTF-8. Donc du russe ou du chinois par exemple, et sans récuperer les caractères spéciaux scandinaves / slaves / francais majuscule accentué / etc...

Pour l'instant j'utilise la requete suivante qui me permet de detecter tout les caractères spéciaux en dehors de la liste suivante:
0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz*-/().''&`,@"+:>!;%$#?^=/.|\{}_[]

SELECT * FROM table WHERE LENGTH(TRIM(TRANSLATE( champs ,' ','0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz*-/().''&`,@"+:>!;%$#?^=/.|\{}_[]'))) > 0 with ur;

A noter que le 2eme champs du translate est mal retranscrit sur le site (ou je m'y prends mal). Il y a autant d'espaces que de caractères en fait pour spécifier par quoi remplacer chaque caractère trouver dans le 3eme champs.

Si je passe la requete je récupère donc des enregistrement qui ont par exemple pour valeur: "LÈVY" mais que je souhaiterais éliminer.

Sauf que quand j'insère le "È" dans ma requete, elle plante:

SELECT * FROM table WHERE LENGTH(TRIM(TRANSLATE( champs ,' ','0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz*-/().''&`,@"+:>!;%$#?^=/.|\{}_[]È'))) > 0 with ur;

SQL0103N The numeric literal
"0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz" is not valid.
SQLSTATE=42604

Est ce qu'il est possible avec TRANSLATE de remplacer aussi ce type de caractère qui est sur 2 octets par du space?
Faut il que je change la representation du "È" (concatenation de la chaine avec la représentation hexadécimale?)?
Ou fait je completement fausse route et il faut que j'utilise une autre méthode?

Merci.

[escartefigue]

Bonsoir,

Quelle est la volumétrie de la table, les fonctions de colonne sur le where, à part sur une petite table, risquent de rendre la requête particulièrement longue.
En ce cas il vaut mieux faire un unload et travailler sur le fichier

Sinon il est bien sur possible de tester la valeur hexa d'une chaine : where col = X'...'

[Tylert]

Bonsoir,

Quelle est la volumétrie de la table, les fonctions de colonne sur le where, à part sur une petite table, risquent de rendre la requête particulièrement longue.
En ce cas il vaut mieux faire un unload et travailler sur le fichier

Sinon il est bien sur possible de tester la valeur hexa d'une chaine : where col = X'...'

Malheuresement on est pas sur de petites volumétries... 60 et 50 millions de lignes respectivement pour les deux tables dans lesquelles je dois faire mes recherches... (Noms et addresses).

[escartefigue]

Pour rappel, les fonctions de colonne interdisent l'usage des index, c'est pourquoi un déchargement par unload puis traitement par programme me semble plus adapté qu'une requête.

[Tylert]

Pour rappel, les fonctions de colonne interdisent l'usage des index, c'est pourquoi un déchargement par unload puis traitement par programme me semble plus adapté qu'une requête.

MErci pour les infos.

J'ai fait ma recherche dans l'autre sens finalement. J'ai cherché si les 3 premiers caracteres de mon champs correspondaient a une chaine d'un caractère chinois:
db2 "select * from table where substr(champs,1,3) in (X'e4b880',X'e4b881', ... etc) with ur"

La liste n'est pas exhaustive car il faudrait aussi rechercher les noms avec des caractères chinois au milieu de caractères latins, mais au moins je sais maintenant qu'il y a des caractères chinois dans la base.
La recherche doit aussi se faire en plusieurs requetes, car il y a enorméments de caractères chinois et tout ne tiens pas en une seule requete (en tout cas, sous unix je suis limité à des requetes de 2000 caractères).

[escartefigue]

MErci pour les infos.

J'ai fait ma recherche dans l'autre sens finalement. J'ai cherché si les 3 premiers caracteres de mon champs correspondaient a une chaine d'un caractère chinois:
db2 "select * from table where substr(champs,1,3) in (X'e4b880',X'e4b881', ... etc) with ur"
.

Requete non sargable (fonction substr), sur 60 millions de lignes ca va prendre un temps certain !

[Luc Orient]

Requete non sargable (fonction substr), sur 60 millions de lignes ca va prendre un temps certain !

... encore faudrait il qu'il y ait un index sur la colonne en cause, ce que, a priori, on ne sait pas ...

[escartefigue]

... encore faudrait il qu'il y ait un index sur la colonne en cause, ce que, a priori, on ne sait pas ...

encore moins, si pas d'index c'est par définition non sargable
Ce que je mentionne c'est que même si index il y a, le substring interdit son utilisation, sur une table de cette volumétrie, ce n'est pas neutre

[Tylert]

La requete était un one shot. Oui, ca a pris un certain temps... mais il n'y avait pas d'utilisateur qui patientait derriere son écran...
donc pas grave

Merci pour les retours.