Discussion :

[essence-ciel]

Bonjour,
Je suis en train de migrer, laborieusement il est vrai (car je découvre le SQL et SQLite), une application de Paradox/BDE vers SQLite/Firedac .
OS : Windows 8/10, RadStudio Professional 10.3.3/10.4.3 (pc domicile/pc cabinet de soins). Version SQLite (pour le moment) 32 bits. Cela fait plusieurs jours que je rencontre un sérieux écueil...

NOTA : Les descripteurs de fichier sont les mêmes sous Paradox et SQLite (Pas de BLOB ni de Text).

Avec SQLite :
Toutes les tables ont une FOREIGN_KEY vers "Produits" avec comme champ clé NumM.
Toutes les tables ont une PRIMARY_KEY INTEGER non auto-incrémentée.
Toutes les tables sont en plus indexées sur un identifiant unique.

Dans le programme original, avec Paradox/BDE j'effectue cette requête :
(NumM et Indic/Affection étant des champs communs aux différentes tables)

Code :

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

1
2
3
4
SELECT DISTINCT D.Affection, D1.Organe, D1.Indic, D1.CT, D1.VVT, D1.Rem, D1.Eff, D1.Compl, D2.Nom, D2.HE
FROM "Affections" D, "HEIndic" D1, "Produits" D2
WHERE (D1.Indic = D.Affection) AND (D2.NumM = D1.NumM) AND (D2.HE = True)
ORDER BY D.Affection, D2.Nom

et j'obtiens :


avec la même requête avec SQLite/FireDac, soit :



j'obtiens une table avec des colonnes vides... quant à SQLite Studio, il me jette proprement et simplement avec comme message d'erreur :



Depuis, j'ai modifié le champ "Affections" en "Affection" (Merci SergioMaster) pour faciliter la lecture et gagner en cohérence, même résultat...

J'ai eu beau tester la même requête avec SQLite Studio, dBBrowser pour SQLite ou l'éditeur SQL de RadStudio, rien n'y fait, j'obtiens toujours le même résultat... c'est à dire des colonnes vides si ce n'est le descripteur des colonnes...

Si quelqu'un a une idée, merci. Je suis preneur de toute observation.

bien cordialement,

[SergioMaster]

Bonjour

Depuis, j'ai modifié le champ "Affections" en "Affection" (Merci SergioMaster) pour faciliter la lecture et gagner en cohérence

oui, bon ce n'est qu'un détail de peu d'importance

Toutes les tables ont une PRIMARY_KEY INTEGER non auto-incrémentée.

non incrémentée ! là ça me choque, c'est a contrario, l'objectif de ces identifiants "techniques"

Parlons en de la requête

Code :

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

1
2
3
4
SELECT DISTINCT D.Affection, D1.Organe, D1.Indic, D1.CT, D1.VVT, D1.Rem, D1.Eff, D1.Compl, D2.Nom, D2.HE
FROM "Affections" D, "HEIndic" D1, "Produits" D2
WHERE (D1.Indic = D.Affection) AND (D2.NumM = D1.NumM) AND (D2.HE = True)
ORDER BY D.Affection, D2.Nom

cette utilisation des tables est totalement "has been", héritée de BDE mais il vaut mieux formuler les jointures autrement

Code :

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

1
2
3
4
5
6
SELECT DISTINCT D.Affection, D1.Organe, D1.Indic, D1.CT, D1.VVT, D1.Rem, D1.Eff, D1.Compl, D2.Nom, D2.HE
FROM Affections D  
       JOIN HEIndic D1  ON D1.Indic = D.Affection
       JOIN  Produits D2 ON D2.NumM = D1.NumM
WHERE D2.HE = True
ORDER BY D.Affection, D2.Nom

un gros avantage : cela sépare les relations (jointures) des conditions

N.B. pourquoi le DISTINCT !?

J'ai eu beau tester la même requête avec SQLite Studio, dBBrowser pour SQLite ou l'éditeur SQL de RadStudio, rien n'y fait, j'obtiens toujours le même résultat... c'est à dire des colonnes vides si ce n'est le descripteur des colonnes...

Et c'est là où lire le tutoriel de SQLPro (Frédéric Brouard) sur les jointures prend tout son sens !
De même que lire l'ensemble de ses "petits papiers" d'ailleurs
Il y a plusieurs sortes de jointures (LEFT, RIGHT, FULL, etc.), ce que j'ai occulté dans ma correction précédente pour "copier" ce que faisait le BDE : des jointures "par défaut"

Code :

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

1
2
3
4
5
6
SELECT D.Affection, D1.Organe, D1.Indic, D1.CT, D1.VVT, D1.Rem, D1.Eff, D1.Compl, D2.Nom, D2.HE
FROM Affections D  
      LEFT JOIN HEIndic D1  ON D1.Indic = D.Affection
      LEFT JOIN  Produits D2 ON D2.NumM = D1.NumM
-- WHERE D2.HE = True
ORDER BY D.Affection, D2.Nom

Le SQL ci dessus ne fera pas la même chose

en gros il extraiera de la base de données toutes les affections qu'elles aient ou non une indication et un remède .

Mais, sans tester, je crains que cela ne soit pas la "bonne" requête : AMHA une affection pourrait avoir plusieurs indications possibles voire plusieurs remèdes possibles pour une indication ?
de même la clause WHERE que j'ai commentée, il faudrait certainement plutôt l'écrire WHERE COALESCE(D2.HE,False)=True (non testé)

[essence-ciel]

Merci SergioMaster pour les infos et la piste à explorer. Je vais potasser les explications de Frédéric Brouard sur les jointures.

En ce qui concerne les tables avec les identifiants non auto-incrémentés, comme indiqué dans la documentation SQLIte en ligne, je pensais récupérer le dernier ROWID de la table et l'incrémenter par programme ou laisser faire SQLite... enfin si j'ai bien compris les possibilités de SQLite.

En fait, ce que je cherche à faire c'est pour une affection donnée (AFFECTION), lister toutes les huiles essentielles (HE) qui traitent ce problème, tout en mentionnant les remarques (REM), les compléments (COMPL), l'organe producteur (ORGANE), l'efficacité (EFF) et la valeur thérapeutique (VT) en provenance des tables AFFECTIONS, HEINDIC et PRODUITS. Sachant que le numéro de produits NUMM est repris dans la table HEINDIC et que dans HEINDIC j'ai un champ référence qui pointe sur AFFECTIONS.AFFECTION

Je vais m'intéresser à COALESCE également. Merci du tuyau.

[SergioMaster]

En ce qui concerne les tables avec les identifiants non auto-incrémentés, comme indiqué dans la documentation SQLIte en ligne, je pensais récupérer le dernier ROWID de la table et l'incrémenter par programme ou laisser faire SQLite... enfin si j'ai bien compris les possibilités de SQLite.

Laisser faire SQLite c'est mieux.

En fait, ce que je cherche à faire c'est pour une affection donnée (AFFECTION), lister toutes les huiles essentielles (HE) qui traitent ce problème, tout en mentionnant les remarques (REM), les compléments (COMPL), l'organe producteur (ORGANE), l'efficacité (EFF) et la valeur thérapeutique (VT) en provenance des tables AFFECTIONS, HEINDIC et PRODUITS. Sachant que le numéro de produits NUMM est repris dans la table HEINDIC et que dans HEINDIC j'ai un champ référence qui pointe sur AFFECTIONS.AFFECTION

c'est bien ce que j'avais compris ou du moins supposé. Par contre j'aurais peut-être changer l'ordre des Tables (oui ça joue) en commençant par HEINDIC mais bon ce n'est qu'un point de vue

Je vais m'intéresser à COALESCE également.

Pour COALESCE je n'ai pas vérifié côté SQLite (flemme ou oubli ?)

[essence-ciel]

Bonjour,
Merci pour les observations, cela permet toujours de progresser.

Dans le désordre...
Coalesce existe bien en SQLite, je m'y intéresse donc même si ce n'est pas ma priorité.

En ce qui concerne la requête, j'ai pensé à simplifier le problème en faisant une relation Maître/Détail entre AFFECTIONS et le fichier SQL obtenu par la clause JOIN. Ne me reste plus qu'à finaliser cette requête avec 2 tables au lieu de 3, ce qui semble plus simple, pourtant...

Si j'ai bien compris, INNER JOIN permet l'accès aux données (lignes et colonnes) de la table jointe, or pour la requête suivante avec SQLite Studio :

Code :

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

1
2
3
4
5
SELECT D.INDIC, D.REM, D.ORGANE, D.EFF, D.VVT, D.COMPL
FROM HEINDIC D
    INNER JOIN PRODUITS C ON D.NUMM = C.NUMM
    WHERE C.HE = true
ORDER BY D.INDIC, D.REM, C.NOM, D.ORGANE, D.COMPL

Pas de message d'erreur mais j'obtiens une table vide si ce ne sont les entêtes de colonnes où le champ NOM n'apparaît pas... J'ai la même chose avec dbBrowser pour SQLite. J'ai le même résultat en enlevant la clause WHERE.

Pourtant NUMM est bien commun aux deux tables. C'est un numéro unique dans la table PRODUITS et toutes les autres tables (qui peuvent avoir plusieurs lignes avec ce numéro) pointent vers ce numéro par le champ commun NUMM. Et les enregistrements des tables présents...

table HEINDIC
Pièce jointe 580795

table PRODUITS
Pièce jointe 580796

Cordialement,

[SergioMaster]

Bonjour,

les pièces jointes ne le sont pas, donc difficile de se faire une idée.
Le mieux serait peut-être de fournir la base complète (ou partie de celle-ci, en tout cas un jeu d'essai), de cette manière (je/nous) pourrions peut-être voir ce qui ne fonctionne pas

[essence-ciel]

Bonsoir SergioMaster,

Ici, à Nouméa, il est 18h20 (09 heures de décalage horaire avec la métropole), je sors de massage et prends connaissance à l'instant de ta réponse (j'embraye sur ton genou, non pardon je/nous). Merci de t intéresser à ce problème qui pour moi est épineux car il m'empêche d'achever cette migration tant espérée. En fonction de mon emploi du temps de demain, je te fais parvenir les tables (un extrait me paraît difficile car je ne suis pas certain des correspondances) demain, descriptif des tables + données. Ceci étant, même si je suis impatient, l'urgence n'est pas avérée mon vieux logiciel tourne encore sous Paradox/BDE débuté en 1998 avec un successeur de TurboPascal.

De mon côté, j'ai testé, sans plus de succès, à partir de VIEW, ayant lu qu'une VIEW était un succédané de SELECT...

Durant le massage, bien que concentré, j'ai imaginé que cela pouvait provenir d'une mauvaise installation de SQLite, voire d'un virus... j'avoue être foncièrement dépité et ne plus savoir qu'en penser...

un grand merci pour ton aide car malgré un BTS informatique, il y a quelques années (par pudeur, je ne préciserais pas...), les choses ont bien changé depuis.

Cdlt,

[SergioMaster]

Ici, à Nouméa, il est 18h20 (09 heures de décalage horaire avec la métropole),

Veinard

je sors de massage

c'était mon cas hier après midi (je suis un abonné à vie à la kiné)

j'ai imaginé que cela pouvait provenir d'une mauvaise installation de SQLite, voire d'un virus.

.
AMHA Non

un grand merci pour ton aide car malgré un BTS informatique, il y a quelques années (par pudeur, je ne préciserais pas...),

Plus vieux que le mien, malgré ma première vie en tant que scaphandrier ?

[essence-ciel]

Mort de rire... je fête 62 printemps et autant d'hivers, sans compter les jours heureux, dans 15 jours...

[SergioMaster]

Tu es à ma traine et je compte encore mes 997 jours (enfin sous la barre des milles) avant la retraite (repoussée à cause de ma vie à l'étranger)

[SQLpro]

Putain, mais y'a que des croulants dans ce forum.... !

Moi j'espère la retraite à Noël 2024 !

A +

[al1_24]

J'y serai bien avant toi

[SergioMaster]

Oui, bon je suis obligé d'aller jusqu'au 67 sinon j'y serai déjà depuis 2 ans

Putain, mais y'a que des croulants dans ce forum.... !

je change d'avatar bientôt, d'un pseudo Einstein actif à un druide bedonnant, promi

[fsmrel]

Bonsoir les enfants,

Putain, mais y'a que des croulants dans ce forum....

Et même des croulants++, gamin ! A l’époque où SergioMaster est né, je passais mon bac...

pourquoi le DISTINCT !?

Dans SQL AND Relational Theory, le maître du relationnel, Chris Date, a écrit à propos de SQL :

DISTINCT is the default for UNION, INTERSECT, and EXCEPT; ALL is the default in the other cases.

Et, bien qu’il en soit désolé, il estime prudent de ne pas mégoter avec DISTINCT.
A moins d’être absolument sûr de son coup (et SQL n’étant que modérément relationnel), pour paraphraser Date, autant user et abuser de DISTINCT, ça permet de dormir sur ses deux oreilles, paisiblement. Après mes 35 ans de SQL je ne peux qu’en convenir.

Et vive les huiles essentielles !

[SergioMaster]

Bonjour,

Et même des croulants++, gamin ! A l’époque où SergioMaster est né, je passais mon bac...

du coup, je comprend le titre de Expert éminent sénior
Si ça continue cette discussion va encore changer de titre ( l'ajout "sujet conseillé aux membres nés avant 1965" , perso j'avais pensé à la tribu TAMALOU TUPRENDKOI )

Pour ce qui est du DISTINCT dont je doutais c'était plus parce que je pensais que la structure de la BDD rendait celui-ci inutile. Tant que l'on aura pas la base difficile de l'écrire mais j'y crois.

PS. Je n'ai jamais réussi physiquement à dormir sur mes deux oreilles, si quelqu'un à une explication à cette expression, je prends

[essence-ciel]

Bonjour,
Ravi de faire partie du club...

Entre deux massages, j'ai eu le temps de faire un extrait de ma BDD mais l'interface pour joindre le fichier ne la charge pas ou tourne dans le vide ("parcourir" n'ouvre aucune fenêtre...). J'ai l'impression d'être poursuivi par la haine et entubé par le destin ! Enfin, je joins les descripteurs, enfin j'essaie...

Vous allez rire, mais il paraît que les problèmes d'internet en Calédonie proviennent du câble sous-marin qui est mordu régulièrement par les requins... je le vends pour le prix que je l'ai acheté...













Revenons à nos moutons... Toutes les tables sont liées par NUMM à la table Produits. Il y a des index secondaires uniques ou composés pour chaque table.

Bonne soirée à tous, nous venons d'ouvrir un Château Carbonnieux blanc pour poser la journée. A la santé des Anciens !

[SergioMaster]

Tu dois pouvoir joindre un Zip de ta base (effectivement pas un .sdb3) et il y a quand même une limite de taille.
Sinon, par mp on peut s'échanger (par on j'entends ceux qui veulent se pencher dessus) nos "vrais" email

câble sous-marin qui est mordu régulièrement par les requins

Souvenirs de mon ancienne vie pro, peut-être que dans les Caraibes les requins sont moins féroces en tout cas je n'ai jamais vu de cables machouillés lors de visites de contrôle de cables sous marins (généralement enfouillés à quelques distances de la côte) mais bon à cette époque Internet n'était qu'une vague idée les requins seraient-ils branchés

[fsmrel]

Bonsoir les enfants,


Dans le post #16, la structure des tables PRODUIT et HEINDIC est source d’interrogations.

Si la case à cocher "NN" concerne le bonhomme NULL (j’interprète "NN" comme abréviation de "NOT NULL"), alors, de ce que je vois, toutes les colonnes des tables PRODUIT et HEINDIC peuvent être marquées NULL (selon la norme SQL, seules les colonnes entrant dans la composition des clés primaires sont à considérer de facto par les SGBD comme non nullables, que l’on code NOT NULL ou pas). En particulier l’utilisation de NULL s’avère particulièrement redoutable pour les colonnes entrant dans la composition des clés étrangères.

Histoire de démarrer dans des conditions initiales de température et de pression, il serait bien que vous fournissiez les CREATE TABLE de ces deux tables, au format SQL, afin qu’avant de pratiquer l’autopsie, on puisse tenter un début de diagnostic...

Comme je ne pratique pas SQLite et pour fixer les idées, je prends le code ci-dessous à titre d’exemple, selon lequel les employés sont rattachés à des bureaux :

CREATE TABLE BUREAU
(
bureauId      INT          NOT NULL,
codeBureau    VARCHAR(4)   NOT NULL,
nomBureau     VARCHAR(48)  NOT NULL,
CONSTRAINT BUREAU_PK PRIMARY KEY(bureauId),
CONSTRAINT BUREAU_UK UNIQUE(codeBureau)
) ;

CREATE TABLE EMP
(
empId            INT           NOT NULL,
matricule        VARCHAR(6)    NOT NULL,
nomEmp           VARCHAR(40)   NOT NULL,
bureauId         INT           NOT NULL,
CONSTRAINT EMP_PK PRIMARY KEY (empId),
CONSTRAINT EMP_UK UNIQUE (matricule),
CONSTRAINT EMP_BUREAU_FK FOREIGN KEY (bureauId) 
    REFERENCES BUREAU (bureauId)
) ;

Et bien sûr, un début de bout de jeu d’essai comportant des INSERT dans les tables en cause sera le bienvenu.

De mon côté je reprendrai vos CREATE TABLE et votre jeu d’essai pour me créer une base de données dans le contexte SQL Server et investiguer...

[fsmrel]

Pour ce qui est du DISTINCT dont je doutais c'était plus parce que je pensais que la structure de la BDD rendait celui-ci inutile.

Le problème est que SQL n’est pas conforme à la théorie relationnelle. Ainsi, une table doit être un ensemble, or on peut en faire un sac à tuples (tuple bag). Autrement dit SQL n’est pas regardant, il fait trop souvent fi de la théorie des ensembles dont la théorie relationnelle est une conséquence...

SergioMaster, ça fait un bon bout de temps que je fréquente le club des Tamalous et, en votre compagnie et celle de essence-ciel (et pourquoi pas celle de ClaudeLELOUP et autres sympathiques séniors), j’espère qu’on y accueillera avec bienveillance les jeunots Al1_24 et SQLpro le jour voulu.

[SQLpro]

L.... et SQLpro le jour voulu.

J'espère avoir la lucidité de me supprimer avant !

Pour cela j'ai pris les devants.... Achat d'un appartement au dernier étage d'une tour....


Bon, y'a quand même la vue !





A +