Vi har lige haft en “spooky” sag hvor der ikke fandtes – og det heller ikke var muligt at lave primo- og ultimo-datoer i en Klassisk Dynamics C5. Det var godt nok på en C5 2010 på SQL, men efter at have fundet fejlen vil jeg tro det umiddelbart vil kunne ske på alle C5-versioner til og med 2012 på SQL.

I C5 så finansperioderne sådan her ud:

Finansperioder unde PR- og UL-datoer

Som det fremgår er der ingen PR.- og UL.-datoer og hver gang man lukkede billedet, fik man mærkelige fejl fra C5.

Efter at have prøvet det oplagte med at genoversætte alt og sådan noget, fik jeg sagen omtalt og mit umiddelbare gæt var at datatypen for datofelterne var forkerte på SQL-serveren (DATE fremfor DATETIME) – hvis du undrer dig over den konklusion, så handler det om hvordan Klassisk Dynamics C5 gemmer primo- og ultimodatoer – se evt. dette blogindlæg, der kort beskriver det.

Det viste sig at det ikke nøjagtigt var det der var galt, men noget i den stil. Kan du spotte den LILLE (hint, hint) fejl 🙂

Forkert SQL tabeldefinition for LEDEPERIOD på kundens installation (Klassisk Dynamics C5 version 2010)

For en ordens skyld får du lige her screenshot af hvordan de korrekte tabeldefinitioner ser ud på SQL på hhv. Klassisk Dynamics C5 3.0 SP3 (som jo er på dansk)…:

SQL tabeldefinition for FINPERIODE på Klassisk Dynamics C5 version 3.0 SP3

…og Klassisk Dynamics C5 2012:

SQL tabeldefinition for LEDEPERIOD på Klassisk Dynamics C5 version 2012

For dem der ikke kender den nøjagtige forskel på en smalldatetime og en datetime på SQL, kan jeg fortælle at den vigtigste i denne forbindelse er at smalldatetime afrundes til hele minutter (se evt. andre forskelle her: http://sqlhints.com/tag/datetime-vs-smalldatetime/). Det gør en kæmpe forskel på netop primo- og ultimodatoer da disse lagers som hhv. kl. 00:00:58 dagen før den pågældende dato eller som 00:00:02 på den pågældende dato – og dermed sorteres naturligt. Andre tidspunkter end 00:00:58 (primo) og 00:00:02 (ultimo) ignores mig bekendt helt af C5.

Hvordan pokker og hvornår datetime er blevet til smalldatetime i kundens installation er uvist, men det er noget værre rod! Det kan være nogen har pillet med C5s interne mapning af datatyper da databasen i sin tid blev oprettet eller at nogen efterfølgende har kørt noget på SQL-serveren, der har rettet det. Kunden har jf. backup’erne kørt med dette i årevis uden at have bemærket problemer.

Vores bedste bud på at komme videre var derfor multiexport af data, oprettelse af ny SQL database med check af at datoer bliver gemt som datetime og endelig multiimport af data. Og naturligvis derefter en grundig oprydning alle de steder hvor primo/ultimo er blevet gemt som “rigtige” datoer.

Det er første gang jeg har set denne fejl – og jeg har arbejde med Klassisk Dynamics C5 i over 20 år, men forhåbentligt også den sidste…