Requête SQL Balance Agée SAGE 100C

Bonjour ,
Je cherche à faire une requête pour extraire la balance agée du logiciel Sage100C V10.
Nous utilisons MSSQL Serveur sur un serveur Windows 2022 :
Voici la requête que j'ai faite :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

select fe.CT_Num , SUM(CASE WHEN DATEDIFF(DAY, fe.EC_Echeance, GETDATE()) <=0 THEN fe.EC_Montant ELSE 0 END) AS 'NonEchu', SUM(CASE WHEN DATEDIFF(DAY, fe.EC_Echeance, GETDATE()) BETWEEN 1 AND 30 THEN fe.EC_Montant ELSE 0 END) AS Ech30, SUM(CASE WHEN DATEDIFF(DAY, fe.EC_Echeance, GETDATE()) BETWEEN 31 AND 45 THEN fe.EC_Montant ELSE 0 END) AS Ech45, SUM(CASE WHEN DATEDIFF(DAY, fe.EC_Echeance, GETDATE()) BETWEEN 46 AND 60 THEN fe.EC_Montant ELSE 0 END) AS Ech60, SUM(CASE WHEN DATEDIFF(DAY, fe.EC_Echeance, GETDATE()) > 60 THEN fe.EC_Montant ELSE 0 END) AS Echsup60 from F_ECRITUREC fe where fe.JM_Date between '20250101' and '20251030' and fe.cg_num like '411%' and fe.EC_Sens = 0 and fe.EC_StatusRegle = 0 group by fe.CT_Num

---

Où :

fe.ec_ECHEANCE est la date d'échéance
fe.CT_NUM = n° du tiers client
fe.cg_num = Compte comptable
fe.EC_Montant = Montant de l'écriture
F_ECRITUREC =Table des ecritures

Toutefois lorsque je sors l'état d'impression "Balance agée" du logiciel , les valeurs sont différentes .
Est ce que quelqu'un connaissant le logiciel pourrait m'aiguiller et me dire où est mon erreur .
D'avance merci

Bonjour,

L'outil "SQL profiler" permet de "sniffer" les ordres SQL entrants.
Il suffit de paramétrer une trace (bien filtrer pour ne pas en récupérer trop) et de lancer la capture le temps de l'action ciblée.
Ensuite vient le temps de la lecture du résultat.

Faire une "bonne" trace n'est pas si simple ; attendez vous à en avoir trop ou pas ce qui est cherché ou pas assez.
Prévoyez de faire plusieurs tentatives - le mieux étant de le faire en période de faible activité.

Bonjour,

juste comme ça, il ne manquerait pas le 31/10 par hasard ?

Bonjour,
Merci Michel Priori pour votre excellente idée.
J'ai mis une trace et j'ai pu récupérer la procédure qui génère la balance agée SAGE

Citation:

---

Envoyé par olaxius

Bonjour,
Merci Michel Priori pour votre excellente idée.
J'ai mis une trace et j'ai pu récupérer la procédure qui génère la balance agée SAGE

---

Ok,
Mais, du coup, en quoi la requête "maison" était elle erronée ?

Cette restriction m'interpelle :

where fe.JM_Date between '20250101' and '20251030'
Est-ce que le logiciel SAGE stocke les dates dans des colonnes de type (var)char ? :aie:

Citation:

---

Envoyé par escartefigue

Cette restriction m'interpelle :

where fe.JM_Date between '20250101' and '20251030'
Est-ce que le logiciel SAGE stocke les dates dans des colonnes de type (var)char ? :aie:

---

Non :D
La conversion d'un texte vers date est implicite ; il suffit que le texte suive le format 'yyyymmdd hh:mm:ss.mmm' (format ISO) pour ne pas avoir de problème d'interprétation.
Sinon, effectivement il faut passer par la fonction CONVERT pour faire la transcription d'un littéral en date.
voir ici : https://learn.microsoft.com/fr-fr/sq...l-server-ver17

Certes, mais en ce cas :

• les dates ne sont pas fiabilisées par le SGBD, on peut donc trouver des valeurs aberrantes si l'application a des failles, ce qui n'arrive jamais avec des colonnes de type date ;
• si la conversion est opérée dans une restriction ou une jointure de la table accédée, les index ne sont pas éligibles, tant pis pour les performances ;
• l'espace de stockage est pénalisé, en interne, un type date ne nécessite que 3 octets, contrairement à un type (var)char.

Citation:

---

Envoyé par escartefigue

Certes, mais en ce cas :

• les dates ne sont pas fiabilisées par le SGBD, on peut donc trouver des valeurs aberrantes si l'application a des failles, ce qui n'arrive jamais avec des colonnes de type date ;
  [...]
• l'espace de stockage est pénalisé, en interne, un type date ne nécessite que 3 octets, contrairement à un type (var)char.

---

Je ne comprend pas.
L'écriture de la clause Where ne présuppose pas du type de la colonne.

En supposant que la colonne fe.JM_Date soit du type DATE (ou DATETIME ou ...), comment aurais tu écrit la clause where ?

Citation:

---

Envoyé par escartefigue

• si la conversion est opérée dans une restriction ou une jointure de la table accédée, les index ne sont pas éligibles, tant pis pour les performances ;

---

Tu es sûr de ton coup sous SQL server ?

Ce que je veux dire c'est que si la colonne n'est pas une date, alors le transtypage, qu'il soit explicite ou implicite, provoque les effets que j'ai cités.

Si quelqu'un à une instance SQL server sous la main, il pourra vérifier la différence en matière de chemin d'accès entre :

where cast(ma_colonne en date)=valeur et where (ma_colonne)=cast(valeur en date)
Avec un index sur ma_colonne indexée

La première syntaxe n'est pas sargable (index non éligible), la deuxième l'est ;)

Re,

Pièce jointe 671558

Pièce jointe 671559

Du coup la conversion implicite ne provoque pas le phénomène :koi: serait-ce un apport d'une version récente de SQL serer ?
Saurais tu refaire la même requête avec une conversion explicite type where cast(ma_colonne en date)=valeur je pense que là il n'y aura pas de miracle.