Discussion :

[bstevy]

Bonjour à tous,

Voilà, petite question que je me pose : est ce qu'il y a un risque lorsque l'on convertit une colonne d'un certain type en char, notament, sans passer par un opérateur de type

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

cast( as char())

?

Je souhaite savoir s'il y a un type sur lequel ca pourrait créer une erreur, sans tenir compte d'un erreur de longueur...
Je prends le postula que mon char de destination fait 1000 caractères, et que ma source fait forcément moins (on va éviter d'envoyer un blob dans mon char par exemple, car là, je sais que ca va pas passer)

Merci d'avance pour vos retours d'expérience.


Steven

[SQLpro]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT CAST(123456789876543234567898765434567890987654345678 AS CHAR(250))

Msg*1007, Niveau*15, État*1, Ligne*1
Le nombre '123456789876543234567898765434567890987654345678' sort des limites de représentation numérique (précision maximale*38).

Après tout dépend de votre SGBDR.... Avec une passoire comme MySQMerde... difficile de savoir ce qu'il va faire !


A +

[bstevy]

Ouais donc ce genre de problème est intrinséquement lié à la base qu'on utilise....

Typiquement, je suis sur oracle, et l'exemple que vous avez donné fonctionne parfaitement bien.

Et ce que je veux savoir, c'est surtout ce qu'il se passe lors d'une convertion implicite.
Typiquement, en PL/SQL, le script que j'étudie récupère dans une variable de type char (pour sortir l'information dans un fichier) tout un tas de données, et le cast n'est jamais utilisé.
Je voulais donc savoir s'il fallait que je corrige ca car y'a un risque certain, ou si le risque et minime et donc si je peux me concentrer sur d'autres corrections en attendant.

[StringBuilder]

Un risque potentiel, bien présent avec JavaScript (on, s'éloigne du SQL), c'est le choix de la base pour la représentation du nombre en sortie.

En effet, un paramètre X ou Y peut faire en sorte que la conversion implicite de la valeur numérique 255 ne soit pas "255", mais "FF" ou "0x000000FF", "11111111" ou encore "377" (base 8).

Par exemple, en JavaScript, "paserInt(11)" sans autre argument n'est pas égale à 11 mais à 9 car par défaut c'est en base 8.

Autre risque potentiel, l'encodage indésirable.

Si vous avez un fichier encodé par exemple en UNICODE 16, la conversion implicite peut éventuellement produire du ASCII 7 bits ou inversement, et ainsi introduire des caractères déconnants dans votre fichier de sortie.

Après, ceci dit, une bête conversion genre "to_char(n)" produira sans doute les mêmes risques : il faut jouer avec les paramètres de conversion et d'encodage.