19. februar 2010 - 13:44Der er
10 kommentarer og 1 løsning
Beregninger med int og decimal i sql
Jeg har brug for i en MS SQL-database at konvertere fødselsdatoen i et cpr-nummer (char) til decimal(9,4) i form af fødselsåret (4 cifre) før kommaet og antal dage siden nytår div med 366 som decimal. Det går fint med indtil jeg skal beregne decimaltallet ved brug af YEAR(), MONTH() og DAY(), jf. nedenstående kode. Så kommer det ud som yyyy,0000.
SET DATEFORMAT dmy; GO UPDATE lbnr.cpr_test SET Foedsdag_char = LEFT(CPR, 2) + '.' + SUBSTRING(CPR,3,2) + '.' + SUBSTRING(CPR,5,2); UPDATE lbnr.cpr_test SET Foedsdag_date = CONVERT(smalldatetime, Foedsdag_char, 4); UPDATE lbnr.cpr_test SET Foedsdag = DAY(Foedsdag_date), Foedsmaaned = MONTH(Foedsdag_date), Foedsaar = YEAR(Foedsdag_date); UPDATE lbnr.cpr_test SET Foedsdag_decimal = Foedsaar + (30 * (Foedsmaaned - 1) + Foedsdag) / 366;
Så vidt jeg har kunnet finde ud af på diverse hjemmesider, online-hjælp m.m., skulle der ikke være problemer med at bruge tal i int-format til beregninger, der skal resultere i det decimal-resultat, så hvorfor kommer decimalerne ikke med?
Det lykkes for mig at beregne med decimaler ved brug af nogle længere beregninger med talrige forekomster af CONVERT() og SUBSTRING(), men det bliver noget uoverskueligt, når beregningerne ved hjælp af IF-sætninger skal tage højde for det forskellige antal dage i månederne, så derfor ville jeg gerne simplificere det på ovenstående måde.
Håber, at nogen kan hjlpe mig, eller at der måske ligefrem er nogen, der ligger inde med en endnu enklere måde at gøre det på.
Med kunstig intelligens skaber HP’s nye OmniBook X 14 en unik og skræddersyet brugeroplevelse målrettet dem, der ønsker høj ydeevne og intelligente funktioner
Tak for rådet om at bruge 30.0. Det virkede og er klart de 30.0 point værd. Nu jeg ser forklaringen, kan jeg godt huske, at jeg er stødt på det problem (og den løsning) for en del år siden i en eller anden sammenhæng (GIS, programmering el. lign.), der med sikkerhed ikke har noget med sql at gøre, men jeg er alligevel overrasket over, at det er det, der var problemet. Jeg opfatter det nærmest som en fejl, at systemet ved beregning af decimaltal skelner mellem, om der anvendes 30 eller 30.0 i en multiplikation. Bare for at tilfredstille min nysgerrighed: Er der en logisk grund til denne skelnen? Problemerne med at der er forskellige antal dage i månederne har jeg egentlig løst med 12 separate UPDATE...WHERE, men jeg vil fluks ændre det til brug af DATEPART DY, for det er da en lettere og "smukkere" løsning. Jeg er ny bruger på eksperten.dk, så hvis der af en eller anden grund går noget galt med overførsel af point, må du lige sige til.
Overvej også hvorvidt du virkeligt behøver CPR numre.
Hvis du behøver dem så bør du: - opbevare dem krypteret - have streng bruger kontrol i applikationen - have data politik for hvem der må bruge hvilke data til til hvilket formål - bruge krypteret net-trafik o.s.v.
Forskellen i datoformater er heldigvis ikke noget problem, da jeg kun beskæftiger mig med unge under 18 år. Ellers kunne det jo klares med kontrol med det 7. ciffer. Datasikkerheden er på plads. Jeg sidder i en offentlig forvaltning og har data sikkert opbevaret på en sikkerhedsgodkendt server med alt hvad det indebærer af adgangskontrol, logning m.m.m.
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.