Discussion :

[TOFatJOB]

Bonjour à tous,

dans l'extrait suivant :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
SELECT [STOFCY_0]
      ,[ITMREF_0]
      ,[ITCSEQ_0]
      ,[ITCSTRDAT_0]
      ,[ITCENDDAT_0]
      ,[ZMBIA_0]
  FROM [CLSTREIT].[ITMCOST] 
  where ITMREF_0 = '1010381'  and CSTTYP_0 = 5 and ITCSEQ_0 between 30 and 38
  order by ITMREF_0, ITCSEQ_0

Code :

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

1
2
3
4
5
6
7
8
9
10
 
STOFCY_0ITMREF_0 ITCSEQ_0	ITCSTRDAT_0	ITCENDDAT_0	        ZMBIA_0
100	1010381	30	2021-10-11 00:00:00.000	2050-12-31 00:00:00.000	4.72000
100	1010381	31	2021-10-25 00:00:00.000	2050-12-31 00:00:00.000	4.72000
100	1010381	32	2022-02-01 00:00:00.000	2050-12-31 00:00:00.000	5.68000
100	1010381	34	2022-03-07 00:00:00.000	2050-12-31 00:00:00.000	4.51000
100	1010381	35	2022-05-01 00:00:00.000	2050-12-31 00:00:00.000	4.51000
100	1010381	36	2022-09-06 00:00:00.000	2022-12-31 00:00:00.000	3.77000
100	1010381	37	2022-09-12 00:00:00.000	2022-12-31 00:00:00.000	4.51000
100	1010381	38	2022-10-24 00:00:00.000	2022-12-31 00:00:00.000	4.53000

le champ ITCENDDAT_0 n'est pas exploitable.

Je souhaiterais mettre la base à jour, pour que ce champs soit égal à (ITCSTRDAT_0 - 1 jour) de la ligne suivante.
Pour la séquence 36, le 11/09/2022 par exemple
Ainsi, je pourrai récupérer ZMBIA_0 à date : exemple 3.77 pour une facture datée au 10/09/2022

Je ne peux pas faire ITCSEQ + 1 car il y a des trous (ITCSEQ 33 n'existe pas)

Faisable ? J'ai lu pas mal de post sur des sujets +/- similaires, où le fait que les enregs ne sont pas 'triès' dans la table ouvre pas mal de discussions ...

[AaâÂäÄàAaâÂäÄàAaâÂäÄ]

avec la fonction LEAD, ça devrait être faisable.

[escartefigue]

Bonjour,

En effet les fonctions LAG() et LEAD() permettent de faire ce genre de choses, mais s'il s'agit de mettre à jour chaque ligne pour y mettre la valeur de la ligne précédente ou suivante, alors ce n'est pas recommandé :
si la valeur de la ligne précédente ou suivante change, la valeur de la colonne ainsi calculée deviendra fausse. C'est pourquoi il est préférable de calculer la valeur par requête, éventuellement au moyen d'une vue. Sauf s'il s'agit de figer une valeur à un instant "t", auquel cas il me semble qu'un horodatage accompagnant cette valeur serait le bienvenu.

[TOFatJOB]

Bonjour,

j'ai réussi avec LEAD à faire ce que je voulais, merci à vous.

Pour ceux que cela pourrait aider :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
--UPDATE ligne X en utilisant une donnée de la ligne X+1 (ici date de fin) 
--On alimente date de fin avec date début de la ligne suivante, ainsi on peut récupérer une MB à date
--Lors de la rupture ARTICLE, CLIENT ... on conserve la date initiale ITCENDDAT_0 , style 31/12/2050
 
with cte as (
Select [STOFCY_0]
      ,[ITMREF_0]
      ,[ITCSEQ_0]
      ,[ITCSTRDAT_0]
      ,[ITCENDDAT_0]
      ,[ZMBIA_0] 
      ,LEAD(ITCSTRDAT_0,1,ITCENDDAT_0) OVER (PARTITION BY ITMREF_0, ZCLIENT_0, ZCLIAAD_0  ORDER BY ITMREF_0, ZCLIENT_0, ZCLIAAD_0, ITCSEQ_0) as NewVal
from [CL].[ITMCOST] 
where  CSTTYP_0 = 5 
)
Update cte
set ITCENDDAT_0 = NewVal;

[escartefigue]

Il n'en reste pas moins que stocker une valeur calculée est très dangereux, car le résultat n'est vrai qu'au moment du calcul...

[TOFatJOB]

Bonjour Escartefigue,

je suis bien en phase avec vos remarques;

Le problème, est que lorsqu'on enregistre une nouvelle valeur ZMBIA_0 avec une date de début, on ne connait pas la date de fin.

Celle-ci sera déduite par l'arrivée d'une nouvelle valeur à date.

Donc si je laisse 31/12/2050 je ne peux pas retrouver la valeur à date ...


! C'est en l'écrivant que je vois : j'aurais peut-être dû faire : date >= date début and date < début n+1 en utilisant LEAD

Je vais essayer cela, ce qui éviterait effectivement le UPDATE sur la table.


Merci encore de vos remarques toujours pertinentes.

[Michel.Priori]

Le problème, est que lorsqu'on enregistre une nouvelle valeur ZMBIA_0 avec une date de début, on ne connait pas la date de fin.
Celle-ci sera déduite par l'arrivée d'une nouvelle valeur à date.
Donc si je laisse 31/12/2050 je ne peux pas retrouver la valeur à date ...

Plusieurs remarques :
* Mettre une valeur remarquable (et fausse) pour signifier 'on ne sait pas' n'est utile que si le SGBD ne sait pas indexer les NULL ; SQL server indexe les NULL.
* Si la date de fin est connue lors de l'insert d'un autre évènement, alors un trigger devrait faire le TAF. - A voir s'il n'est pas plus judicieux d'avoir l'ID de la ligne remplaçante plutôt que dupliquer la date sur les 2 lignes