Discussion :

[freud]

Bonjour,

Il y a une chose que je n'ai pas comprise.....
Lorsqu'on défini dans une table un champ Varchar (30) et que dans une PS lors d'un insert/update ce même champ est de 25 suite à une erreur. Pourquoi FB ne fait pas automatiquement la troncature il me semble que certain SGBD le font, non ? A la place il nous renvoi le message et donc ca reste bloquer:

Code :

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

1
2
3
4
5
6
7
8
 
Message: Dynamic SQL Error
SQL error code = -303
arithmetic exception, numeric overflow, or string truncation
string right truncation
expected length 100, actual 150
Incompatible column/host variable data type
GDS Code: 335544569 - SQL Code: -303 - Error Code: 249

De plus ca n'affiche pas le nom du champ ca aurait été plus simple pour dépister si on avait de nombreux champs de type chaine.

Merci.

[SQLpro]

Qu'attendez vous pour changer de SGBDR ???

Plus sérieusement, SQL est un langage typé et le type VARCHAR(30) n'est pas égal au type VARCHAR(25). Il en résultera des conversions implicites qui vont pourrir vos performances....

À vous d'être intelligent !

A +

[freud]

Bonsoir,

Qu'attendez vous pour changer de SGBDR ???

Tout à fait juste, soit on accepte soit on change de SGBD et puis c'est une ingratitude pour un gratuit pareil.
Enfin oui, suffit de faire attention à ce que l'on fait.

Merci à vous.

[SergioMaster]

Bonjour,

[Mode Troll]
C'est n'est pas forcément de SGBDR qu'il faut changer de la personne qui n'a pas bien documenter la BDD !
[/Mode]

Plus sérieusement il faut quand même un minimum de rigueur. C'est vrai, Firebird n'est pas très explicite dans ce type de message. Pourquoi ne pas proposer aux auteurs une modification ? Après tout Firebird est un vrai Open Source !
@SQLPro oui, PostgresQL aussi mais nous sommes dans le forum Firebird.

Tout dépend également de l'outil que vous utilisez lorsque vous écrivez une procédure certains permettent de les tester en mode debug.

Mais, à mon avis, la rigueur+la documentation sont les maitres mots

[freud]

Bonjour,

Mais, à mon avis, la rigueur+la documentation sont les maitres mots

En effet, mais parfois en outre-passe les règles de base dans certaines situations et pour certaines raisons qui ne favorisent guère le developpement.
En tout cas merci pour vos conseils.

[Artemus24]

Salut Freud.

Lorsqu'on défini dans une table un champ Varchar (30) et que dans une PS lors d'un insert/update ce même champ est de 25 suite à une erreur.

Vous n'avez jamais entendu parlé d'un dictionnaire de données ? Où l'on définit le nom des colonnes ainsi que leur type et leur format dans chaque table !
C'est ce genre de travail que vous devez faire quand vous créez une base de données.
Car vous ne serez plus en mesure de deviner le nom, voir le type de la colonne dont vous avez besoin.

Ce n'est pas un problème de SGBDR car cela retrouve aussi dans des langages de programmation.
On nomme cela des conversions implicites dont les débutants ne maîtrisent pas du tout leurs effets.
En d'autre terme, ce n'est pas le SGBDR qui est en cause mais votre manque de rigueur dans vos développements.

@+

[freud]

Bonsoir Artemus,

Vous n'avez jamais entendu parlé d'un dictionnaire de données ?

Si, et j'ai perdu cette habitude. Mais c'est comme je l'ai dis plus haut, parfois il y a des situations contraignantes qui ne permettent pas de respecter certaines règles de base et donc on s'appui sur notre intuition et ou mémoire pour se rappeler. Evidemment cela peut être épuisant et, par conséquent, sujet à beaucoup d'erreurs. Le problème est que ca n'en est pas vraiment un, puisque j'arrive à interpréter le message et sais d'où cela provient. C'est enervant si une table contient de nombreux champs qui ne sont pas documenter (ce qui arrive à beaucoup de developpeurs....????)

Disons que mon post aurait dû être poster chez l’équipe de FB en leurs proposant l'affichage du champ en question ce qui pourrait simplifier les choses pour des jeunes qui débutent avec FB comme leur 1er SGBD.

Et merci pour vos remarques.
Bon, alors c'est résolu