Discussion :

[essence-ciel]

Bonjour,
Je travaille avec RADStudio 10.3 sous windows 10.

Néophyte en SQLite, je viens de migrer (enfin c'est en cours...) mes fichiers données de Paradox à SQLite, j'actualise le programme, enfin j'essaye... La BDD contient une soixantaine de tables avec chacune un Primary_Key, j'ai ensuite indexé toutes les tables. La connexion est établie et j'ai déposé un DataSet et un FDTable sur le DataModule. Le FDTable passe à Active et je récupère le DataSet dans le dBGrid. Jusque là tout va bien.

BDD : Soins10.Sqlite3
Table : Affection Create Table Affection ("Affection" Text Not Null, "Num" Text, PRIMARY_KEY("Affection"))

Problème : lorsque je désire afficher une liste avec un dBGrid (celui de la VCL), dans dBGrid le format de la colonne Affection de Text est affiché MemoWide et aucune données ne s'affiche, ce qui est logique puisque les types ne correspondent pas...

J'ai cherché dans le forum sans succès. Quelqu'un a-t-il déjà rencontré ce problème ?

Patrick

[essence-ciel]

Précisions...

Le champ Affection est, à l'origine un champ texte de 75 caractères. A l'importation dans le fichier CSV, tout est normal, y compris les accents.

[SergioMaster]

Bonjour,

Tout est dans la déclaration de type de colonne. Petite démonstration :

Code SQL :

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

1
2
3
4
5
6
7
 
CREATE TABLE TESTTEXT (
    ID           INTEGER     PRIMARY KEY AUTOINCREMENT,
    UNVRAIMEMO   TEXT,
    UNMEMOTAILLE TEXT (75),
    UNTEXTE      STRING (75) 
);

Il y a certes une manière de faire de façon à ce que Firedac considère la colonne UNVRAIMEMO comme une chaine (widestring) et non un blob (widememo) mais cela va passer par des utilisations de FormatOptions.maprules, choses complexes qui vont "alourdir" le code et le rendra moins adaptable ensuite donc, à éviter.


Maintenant, plusieurs choses m'interpellent dans vos propos, en vrac

la description de la table AFFECTIONs,
La primary key ne devrait pas être la colonne affection mais la colonne NUM qui, je le suppose est un entier, certainement un autoincrément et donc ne devrait pas être de type TEXT.
Si la colonne affection (il risque d'y avoir confusion entre nom de table et nom de colonne c'est pourquoi j'ai rajouté un s si elle doit être unique fera l'objet d'un contrainte d'unicité
Voilà comment je verrai la chose

Code SQL :

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

1
2
3
4
CREATE TABLE AFFECTIONS (
    NUM       INTEGER   PRIMARY KEY AUTOINCREMENT,
    AFFECTION TEXT (75) CONSTRAINT UNQ_AFFECTION UNIQUE
);

NUM sera utilisé pour les intégrités référentielles.

[essence-ciel]

Bonjour SergioMaster,
Merci pour les explications et surtout le "s" pour éviter les confusions entre table et champ.

J'ai bien pris note pour l'indication de la taille de la chaîne pour que FireDac traite la donnée comme une chaine plutôt que comme un mémo. Cependant comment faire car ni dB Browser (SQLite) ni SQLiteStudio ne permettent de saisir une taille pour la chaîne ? J'ai certainement dû oublier quelque chose quelque part, ceci expliquant cela...


dB Browser(SQLite) : descripteur de fichier


Résultat à l'affichage...


J'ai testé avec FormatOptions.MapRules widestring->widestring, widememo->widestring... , aucun changement.

En ce qui concerne la colonne Num de la table Affections, cela aurait dû effectivement être ma clé primaire unique et autoincrémentée mais comme les données d'"affection" sont uniques, je n'utilise pas cette colonne que j'ai depuis supprimée. Exemple :
Abcès (en général)
Abcès buccal
Abcès chaud
Abcès cutané
Abcès dentaire
Abcès froid
Abcès hépatique
Abcès mammaire
Absence de soif
Acariens
...

Le casse-tête reste entier...

[ALWEBER]

Bonjour, j'avais fait un travail sur le sujet il y a quelques années (Paradox vers autre base), je le retrouve et je te l'envoie

[Paul TOTH]

en SQL c'est VARCHAR(75) qu'il faut utiliser

à noter que dans SQLite les types de données sont informatifs, on peut stocker n'importe quoi dans n'importe quel champ....par contre FireDAC va récupérer cette information pour formater les données, donc VARCHAR(75) c'est plus indiqué que TEXT.

[essence-ciel]

Bonjour, j'avais fait un travail sur le sujet il y a quelques années (Paradox vers autre base), je le retrouve et je te l'envoie

Bonjour AlWeber,

Merci à l'avance et bonne journée.

[essence-ciel]

en SQL c'est VARCHAR(75) qu'il faut utiliser

à noter que dans SQLite les types de données sont informatifs, on peut stocker n'importe quoi dans n'importe quel champ....par contre FireDAC va récupérer cette information pour formater les données, donc VARCHAR(75) c'est plus indiqué que TEXT.

Bonjour Monsieur,
J'ai bien noté pour le type de données SQLinte. J'ai donc bien indiqué Text pour le champ Affection. A tout hasard, dans DisplayWidth j'ai indiqué 75...

En double cliquant sur le FDTable dans l'inspecteur d'objet j'ai pu accéder au BlobType afin de le changer de WidMemo en WideString et à l'activation de la table, j'obtiens le message d'erreur "FDTable1 type inadéquat pour le champ affection, attendu WideString, actuel WideMemo". Ce qui laisse penser que FireDac ne "lit" pas le bon type. Par ailleurs, j'obtiens le même résultat en essayant diverses valeurs : variant, FixedWideChar, WideString...

Dans la base de données SQLite, après avoir modifié le type de données d'"Affection" de TEXT à BLOB (Cela me paraissait quelque peu incongru toutefois) à l'activation de la table j'ai reçu un message : Violation d'accès à l'adresse 5005F926 dans le module rtl260.bpl... Je comprends de cette erreur que le type TEXT est donc bien adapté et que c'est un problème FIREDAC.

[Paul TOTH]

Bonjour Monsieur,
J'ai bien noté pour le type de données SQLinte. J'ai donc bien indiqué Text pour le champ Affection. A tout hasard, dans DisplayWidth j'ai indiqué 75...

En double cliquant sur le FDTable dans l'inspecteur d'objet j'ai pu accéder au BlobType afin de le changer de WidMemo en WideString et à l'activation de la table, j'obtiens le message d'erreur "FDTable1 type inadéquat pour le champ affection, attendu WideString, actuel WideMemo". Ce qui laisse penser que FireDac ne "lit" pas le bon type. Par ailleurs, j'obtiens le même résultat en essayant diverses valeurs : variant, FixedWideChar, WideString...

Dans la base de données SQLite, après avoir modifié le type de données d'"Affection" de TEXT à BLOB (Cela me paraissait quelque peu incongru toutefois) à l'activation de la table j'ai reçu un message : Violation d'accès à l'adresse 5005F926 dans le module rtl260.bpl... Je comprends de cette erreur que le type TEXT est donc bien adapté et que c'est un problème FIREDAC.

en SQL c'est VARCHAR(75) qu'il faut utiliser...mais je crois l'avoir déjà dit.

[SergioMaster]

en SQL c'est VARCHAR(75) qu'il faut utiliser

Effectivement, VARCHAR(75) est le mieux, pour le test j'en étais resté bloqué sur TEXT(75) plus "classique" de SQLITE ou le STRING(75) de longueur fixe.

Ne sachant pas si cela provenait de SQLite ou de Delphi,

c'est un peu des deux :
- problème Delphi (ou du moins Firedac) l'interprétation du type TEXT => WideMemo
du type TEXT (xxx) => WideString de taille fixe (blancs pour remplir les caractères manquants)
du type VARCHAR(xxx) => WideString (null terminated string)
- Problème SQLite uniquement dans la création de la table et du choix du type de composant.

Comment Firedac peut-il y répondre ? C'est le rôle des formatOptions.Maprules (propriétés de la connexion,de la table ou de la requête) mais je déconseille cette utilisation, j'ai d'ailleurs un doute sur la transformation memo en widestring en utilisant cette technique (ça je n'ai pas testé). Il y a déjà quelques temps une.des discussion.s plus générale.s avait été ouverte.s sur ce sujet précis. (faire une recherche dans le forum avec comme mot clé maprules)

A tout hasard, dans DisplayWidth j'ai indiqué 75...

non, là vous avez changé le champ défini avec Delphi, c'est le type de colonne de la table SQLite qu'il faut changé.

ni SQLiteStudio ne permettent de saisir une taille pour la chaîne ?

Pourtant avec SQLiteStudio (que j'utilise au besoin)

En ce qui concerne la colonne Num de la table Affections, cela aurait dû effectivement être ma clé primaire unique et autoincrémentée mais comme les données d'"affection" sont uniques, je n'utilise pas cette colonne que j'ai depuis supprimée.

Non, ne faites pas cette bêtise, au contraire d'un point de vue SYSDBA c'est une hérésie. Vous ne vous en servez pas parce que vous ne savez pas à quoi elle peut servir et pourtant ce sera bien plus pratique.

comme je n'ai pas de vision globale nous allons admettre qu'il s'agit d'homéopathie
exemple : pour une affection vous recommandez tel plante vous avez donc une table principes(id_principe PRIMARY KEY AUTOINCREMENT, principe varchar(80)); (vous remarquez la même structure )
la table recommandations sera crée ainsi Recommandations(id_recommandation integer PRIMARY KEY AUTOINCREMENT, id_affection integer, id_principe integer, posologie varchar(8), ....)
Ainsi vous pourrez écrire des relations de clé étrangère (traduction littérale de FOREIGN KEY) très efficaces.

(id_affection, plutôt que num qui n'est pas parlant tout comme id ou id_technique : quand il y a plusieurs tables cela deviendra vite un casse-tête à la programmation)


Préférrez ce genre de structure plus tard vous ne pourrez que vous en féliciter croyez moi

[Paul TOTH]

En ce qui concerne la colonne Num de la table Affections, cela aurait dû effectivement être ma clé primaire unique et autoincrémentée mais comme les données d'"affection" sont uniques, je n'utilise pas cette colonne que j'ai depuis supprimée. Exemple :
Abcès (en général)
Abcès buccal
Abcès chaud
Abcès cutané
Abcès dentaire
Abcès froid
Abcès hépatique
Abcès mammaire
Absence de soif
Acariens
...

on n'utilise jamais des données comme clé unique, et surtout pas un libellé.
si demain une nouvelle classification, une faute d'orthographe voir une reforme de l'orthographe devait se produire, il faudrait mettre à jour le libellé partout où il est utilisé. l'ID lui ne changera jamais.

la dernière fois que j'ai fait cette erreur (il y a de nombreuses années) c'était pour une gestion de demandes de cartes d'identités/passeport...la préfecture fournissant des formulaires numérotés, j'avais décidé d'utiliser ce numéro comme clé unique...sauf que un jour un employé s'est trompé en saisissant le numéro...et des semaines plus tard, il n'a pas été possible de saisir un numéro de dossier car c'était justement le numéro qui avait été saisi par erreur....situation très embarrassante vu que l'autre dossier était parti en préfecture depuis longtemps...impossible de savoir son numéro. Et imaginons que la préfecture change de logiciel et parte sur une nouvelle numérotation...qu'est ce qui garanti que ce sera compatible ?

autre exemple bateau le numéro de code postal...c'est toujours tentant de l'utiliser comme clé unique, sauf qu'il ne l'est pas unique...à la rigueur le numéro INSEE mais là aussi la liste des communes est révisée régulièrement.

le champ auto incrémenté ne garanti pas l'unicité des données mais il permet à coup sûr d'identifié chaque enregistrement (et de fusionner les ID si nécessaire)...par ailleurs sur SQLite il existe un champ rowid automatique si la table ne possède pas de champ autoincrémenté déclaré explicitement.

[essence-ciel]

bonjour,
Désolé pour la tardiveté de la réponse mais, depuis une semaine, j'ai appliqué vos remarques pleines de bon sens et j'ai modifié tous les descripteurs de fichiers. Maintenant, tous les identifiants clés ont été renommés en ajoutant id_ , tous les index ont pour suffixe _NDX, les triggers _TRIG... C'est effectivement plus lisible et moins casse-tête.
J'ai également adopté le Varchar pour les chaines à longueur variable et le Text pour les chaines à longueur fixe.
Pour répondre à SergioMaster, il n'était pas très loin, je suis phyto-aromathérapeute et j'entretiens une base de données contenant les produits de soin (huiles essentielles ou végétales, les plantes, les hydrolats, les teintures-mères...), les principes actifs, les vertus et les indications thérapeutiques... et ai développé ce petit applicatif pour recenser le tout, je suis donc plus à l'aise avec les plantes, sous diverses formes, et leurs applications qu'avec la programmation et le SQL...
Un grand merci pour tous ces conseils frappés au coin du bon sens.

[SergioMaster]

et pourtant, je viens de revérifier avec une table créée de toute pièce avec SQLiteStudio et en demandant ensuite le DDL de cette table

Code SQL :

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

1
2
3
4
5
CREATE TABLE categories (
    id      INTEGER       PRIMARY KEY AUTOINCREMENT
                          NOT NULL,
    libelle VARCHAR (255) NOT NULL
);

un script sans le Integer donne

[12:29:26] Erreur pendant l’exécution de la requête sur la base de données « madb » : AUTOINCREMENT is only allowed on an INTEGER PRIMARY KEY

le NOT NULL par contre ne semble pas obligatoire

idem avec un script fourni par TMSDatamodeler

Code SQL :

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

1
2
3
4
CREATE TABLE categories (
  id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL,
  libelle VARCHAR(255) NOT NULL
);