Discussion :

[olaxius]

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 :

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

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

[Michel.Priori]

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é.

[TOFatJOB]

Bonjour,

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

[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

[Michel.Priori]

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 ?

[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 ?

[Michel.Priori]

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 ?

Non
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

[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 ;
• 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.

[Michel.Priori]

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 ?

• 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 ?

[escartefigue]

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

[Michel.Priori]

Re,

[escartefigue]

Du coup la conversion implicite ne provoque pas le phénomène 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.

[Michel.Priori]

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.

\o/ et le miracle fut !



Ce qu'on apprend dans le plan d'exécution :

Le littéral est automatiquement considéré comme une variable :



et que l'instruction CAST est traduite en CONVERT

[escartefigue]

Ce n'est pas du tout la même chose, dans la première requête on avait un index seek c'est à dire l'utilisation de la recherche par index, alors que là on a un index scan, c'est à dire un parcours séquentiel de l'index.
Pas de miracle donc