Page History
...
| Code Block | ||||
|---|---|---|---|---|
| ||||
SELECT t1.ValidFrom, t1.FromDate, t1.ToDate, t1.SorId, t1.ParentSorId, t1.HealthInstitutionSorId, t1.ProviderId, t1.ShakId, t1.EntityName, t1.InstitutionOwnerSorId, t1.InstitutionOwnerCvrNumberId, t1.EntityTypeId, t1.EntityTypeName FROM SOR2SorEntity t1 JOIN ( SELECT UniqueCurrentKey, MAX(ValidFrom) as MaxValidFrom FROM SOR2SorEntity WHERE FromDate >= :date_interval OR (FromDate = ( SELECT MAX(FromDate) FROM SOR2SorEntity t3 WHERE t3.SorId = SOR2SorEntity.SorId ) AND (ToDate is NULL OR ToDate > :date_interval) ) GROUP BY UniqueCurrentKey ) t2 ON t1.UniqueCurrentKey = t2.UniqueCurrentKey AND t1.ValidFrom = t2.MaxValidFrom ; |
...
Til den inderste query tilføjes "AND (ToDate is NULL OR ToDate > :date_interval)", da en SorEntity med start udenfor intervallet kun har relevans, hvis den stadig er aktiv . Her kunne man også overveje at sætte den sidste betingelse til "AND (ToDate is NULL OR ToDate > NOW())", for at få dem der stadig er aktive, der ikke har været ændret i perioden. I praksis har det dog givet det samme antal rækker på produktionsdata (muligvis fordi FromDate og ToDate ofte ligger ret tæt, for de inaktive), men med ringere indlæsningsperformance, så det er derfor fravalgt i den nuværende version.inden for intervallet.