Bonjour à tous, et meilleurs vœux à vous, à vos proches, et à tous vos membres et
bénéficiaires !
Sujet peu original, mais je n’ai pas trouvé la solution.
J’ai fouillé les archives et trouvé ce type de sujet, en particulier un exemple datant
de 2017.
MAIS …
- le schéma de la base de données a beaucoup évolué depuis,
- et cela fait 35 ans que je n’ai pas fréquenté assidûment SQL !
Autant avouer que je bloque « un peu » ! ;-)
Au passage, si le schéma UML/Merise était visible quelque part …
Si l’un de vous peut m’orienter, je suis plein de bonne volonté ! ;-)
Très cordialement,
— Jean-Loup DUBREUCQ —
+33 6 07 13 05 20
Hello !
> Le 8 janv. 2023 à 09:07, Jean-Loup DUBREUCQ <jlmd.paheko@jlmd.fr> a écrit
:
> ...
> Au passage, si le schéma UML/Merise était visible quelque part …
A priori le « reverse » depuis SQLite a fonctionné, donc j’ai un beau schéma sous
les yeux !
De là à dire que c’est plus clair ...
— Jean-Loup DUBREUCQ —
+33 6 07 13 05 20
Suite !
> Le 8 janv. 2023 à 09:52, Jean-Loup DUBREUCQ <jlmd.paheko@jlmd.fr> a écrit
:
> ...
>
> A priori le « reverse » depuis SQLite a fonctionné, donc j’ai un beau schéma
sous les yeux !
> De là à dire que c’est plus clair ...
Et bien si, en fait. Il semble que cela fonctionne :
SELECT membres.nom, membres.adresse, membres.code_postal, membres.ville ,
services_users.date, acc_transactions_lines.debit
FROM services_users
JOIN membres
ON membres.id=services_users.id_user
JOIN acc_transactions_users
ON acc_transactions_users.id_service_user=services_users.id
JOIN acc_transactions
ON acc_transactions.id=acc_transactions_users.id_transaction
JOIN acc_transactions_lines
ON acc_transactions_lines.id_transaction=acc_transactions.id
WHERE services_users.id_service=2
… si on considère assez « bêtement » que « services_users.id_service » est en dur
dans la requête. Il y a moyen d’affiner.
Malgré tout, la requête retourne 2 fois trop de lignes, probablement à cause de la
ligne de contrepartie. Pas (encore) trouvé comment éviter ce bug ! Une idée ?
Très cordialement,
— Jean-Loup DUBREUCQ —
+33 6 07 13 05 20
AMHA Les lignes sont en double car pour chaque transaction_lines on a un debit et un
credit, et donc une ligne avec debit=0.
Suggestion: Ajouter à la fin
AND acc_transactions_lines.debit>0
Cordialement
Guy
-----Message d'origine-----
De : Jean-Loup DUBREUCQ <jlmd.paheko@jlmd.fr>
Envoyé : dimanche 8 janvier 2023 13:30
À : aide@paheko.cloud
Objet : Re: [Paheko] Exports pour création d'attestations
Suite !
> Le 8 janv. 2023 à 09:52, Jean-Loup DUBREUCQ <jlmd.paheko@jlmd.fr> a écrit
:
> ...
>
> A priori le « reverse » depuis SQLite a fonctionné, donc j'ai un beau
schéma sous les yeux !
> De là à dire que c'est plus clair ...
Et bien si, en fait. Il semble que cela fonctionne :
SELECT membres.nom, membres.adresse, membres.code_postal, membres.ville ,
services_users.date, acc_transactions_lines.debit FROM services_users JOIN membres
ON membres.id=services_users.id_user
JOIN acc_transactions_users
ON acc_transactions_users.id_service_user=services_users.id
JOIN acc_transactions
ON acc_transactions.id=acc_transactions_users.id_transaction
JOIN acc_transactions_lines
ON acc_transactions_lines.id_transaction=acc_transactions.id
WHERE services_users.id_service=2
. si on considère assez « bêtement » que « services_users.id_service » est en dur
dans la requête. Il y a moyen d'affiner.
Malgré tout, la requête retourne 2 fois trop de lignes, probablement à cause de la
ligne de contrepartie. Pas (encore) trouvé comment éviter ce bug ! Une idée ?
Très cordialement,
- Jean-Loup DUBREUCQ -
+33 6 07 13 05 20
Bonjour,
> Le 8 janv. 2023 à 14:56, Guy Boussand <guy.boussand@outlook.com> a écrit
:
>
> AMHA Les lignes sont en double car pour chaque transaction_lines on a un debit et
un credit, et donc une ligne avec debit=0.
> Suggestion: Ajouter à la fin
> AND acc_transactions_lines.debit>0
Oui, c’est comme cela que je m’en suis sorti !
Merci !
- Jean-Loup DUBREUCQ -