Version imprimable
Bonjour,
je commence à utiliser SQLite pour des tables de travail et là je tombe sur un os
j'ai une table contenant un code alphanumérique (CHAR(5)) le problème c'est qu'à l'affichage de code tels que 00125 il m'affiche 125 !
aussi bien sur un TDBEdit, une TDBGrid etc... et pourtant mon champ est bien un TWideString de longueur 5
C'est certainement un truc idiot, mais je bloque (et évidemment c'est urgent :roll:)
Résolu, en changeant le type de colonne de la table avant : STRING(5) maintenant TEXT(5)
CHAR(5), STRING(5) et TEXT(5), il y a quoi être confus !
Surtout si CHAR(5) se comporte comme un NUMBER(5)
on a dû récemment passer un CHAR(3) vers un CHAR(4) en ORACLE
Par contre pas de recodage forcé, la colonne contient toujours 000 et quand on arrivera à 999 on passera à 1000, pas de ZEROFILL
C'est dans une DB ORACLE 900 tables rien que dans le schéma principal et il y a 40 schémas sur l'EXADATA
Environ mille champ à changer et les DFM avec ces pénibles champs persistants.
Je l'avais aussi vécu en MySQL CHAR(4) vers un VARCHAR(6) sauf que l'on forçait un stockage de la forme 000000 (comme toi)
Sauf qu'un jour chez un client, un vieux serveur applicatif a été redémarré et il pointait sur le nouveau serveur DB
L'application utilisant un XML pour gérer la structure de la DB a provoqué un retour de 00xxxx à 00xx, la cata 000100, 000101, 000102, tout est passé en 0001
Heureusement, un backup du client datait de la veille !
Depuis la mise à jour automatique a été sécurisé et limité à des utilisateurs privilégiés et aussi j'ai changé de société 2 fois depuis :mouarf:
Bonjour,Je pense que cela vient de la manière dont SQLite traite les données stockées en réalisant un typage dynamique entre autres.Citation:
Envoyé par SergioMaster
Tout est la en anglais :
https://www.sqlite.org/faq.html#q3
https://www.sqlite.org/datatype3.html#affinity