[#73060] Systematisk feil bruk ved søk på fødselsdato i 'Søk i alle basar' ?

[Gjest Tore Trollsaas]

Det ser ut til å være en systemfeil i Søk-funksjonen, som gjør at tusenvis av registreringer ikke finnes ved søk på fødselsdato !--- Eksempel: [søk i alle basar] med 'Folk fødde mellom': 1501 'og' 1512 samt 'Førenamn børjar på': ANormal max levealder tilsier at ingen av disse burde være registrert i kilder etter 1620. Jeg finner imidlertid 624 personer som i mest ekstreme tilfelle er oppgitt født i 1508 og gravlagt i 1958. Dette BARE på fornavn som begynner på bokstaven 'A' !----Feilårsak?: Årsaken ser ut til å være feiltolking av fødselsår, når det inneholder hele fødselsdatoen på formatet 'ÅÅÅÅ DDMM' - slik som for Døde i Høyanger 1929-1966 hvor jeg har plukket ut følgende:Lenke hvor jeg bare blant 10 personer finner at alle 10 trolig handteres feil.Blant annet: 364 0204 0904 1958 arb.form. h.v. Ole Andreas Steffensen Nord m -1891 1884 1508 Eid HøyangerSystemet er tydeligvis laget slik at årstallet (her '1884') ignoreres og dag/måned (her '1508') blir tatt som fødselsåret!Mistenker også at søket går direkte på kildedatafelter og ikke på egne søkedatafelter. I så fall oppstår jo spørsmålet om man skal være kildetro og la det står '1884 1508' eller om man skal endre dette til '18840815'. Hadde man brukt separate søkefelter, ville ikke dette vært noe problem.----Flere eksempler: Søker jeg på folk fødde mellom 1601 og 1612 samt fornavn som begynner på A, finner jeg mer enn 5.000 personer. Også her er det en god del ekstremt gamle personer, blant annet gamle Annie, født i 1601 (!) og død i 1988 - dvs 387 år gammel.Søker jeg på folk fødde mellom 1601 og 1612 samt fornavn som begynner på H, finner jeg 2916 personer. Også her en del ekstremt gamle personer, blant annet Håkon født 1610 og død 1981!---Forslag: Dette var noen få eksempler.Skulle anta at dette dreier seg om en god slump med personer som behandles feilaktig og som kanskje bør få sin 'rettmessige plass i historien' om ikke så alt for lenge?Sjekk gjerne samtidig om den samme feilen gjør seg gjeldende for andre typer datoer (f.eks. dødsdato) OG om det er registrert dato/måned uten ledende null (f.eks. 71 eller 701).Med vyrdsam helsing Tore

[Gjest Jan Oldervoll]

Analysen din er bra. Eg veit vel at det går galt med fødselsår i mange tilfelle. Grunnen er at dato/år er skriven på ein 'milliard' forskjellige måtar som det er eit datamaskinprogram som skal tolkast. Det går galt av og til, delvis fordi det er feil, delvis fordi ein datamskin kanpt kan klara tolka det rett, delvis fordi eg ikkje har tenkt at det kan skrivast på eion gjeven måte og ikkje har lagt inn testar som får det til å bli rett. Det siste burde det kunna gå å retta på, utan at eg er i stand til å sei når.

[Gjest Tore Trollsaas]

Heisann. Uten at jeg kjenner løsningen godt nok, antar jeg at en 'vasking'/konvertering av mottatte kildedata er en fornuftig løsning. Derved slipper online-systemet å teste på 'ein milliard forskjellige måtar', samtidig som man er kildetro ved å benytte et vasket datofelt i søkrutinen.En mulig vei ut av dette kan være følgende trinn, hvor Pkt a. til d. utføres på isolert offline utstyr uten vesentlige kostnader eller behov for programendringer. Pkt e. til f. utføres eventuelt i omvendt rekkefølge. Pkt g. til i. utføres på Testsystemet Pkt j. til l. utføres på Produksjonssystemet a. Ny tabell: - Dato_Format med feltene: * FormatID Numerisk * Format_syntaks Tekst (verdieksempel: YYYY DDMM, YYYY DD/MM, YYMMDD, DDMMYY, osv) * Format_korreksjon Tekst (verdieksempel: YYYYMMDD, YYYYMMDD, 18YYMMDD, 19YYMMDD, osv)b. To nye felt (søkefelt)i individenes tabell: * Fodt_Dato_FormatID Numerisk (peker til Dato_Format tabellen). * Fodt_Dato_Search DateTime formatc. I fred og ro kan man så foreta analyser av kildedatofeltene, dokumentere krav til automatiske konverteringsrutiner og oppdatere den nye tabellen og de nye feltene. Deretter kan man foreta avviksanalyser av resultatene, bl.a. matche med registreringsdato og andre forhold.d. Sluttlig gjøres en kvalitetsikring mot dataene av personer som ikke har deltatt i korreksjonsarbeidet, men som med kreative og finurlige kontroller søker å avdekke så mange avvik som mulig. Krav til Konverteringsrutinene oppdateres.e. Automatiserte konverteringsrutiner utarbeides. Full ny konvertering av data foretas vha disse. Avviksanalyse mellom 'manuelt' og 'automatisert' konverterte data gjennomføres, for kvalitetssikring av automatiserte konverteringsrutiner.f. Konverteringsrapport overleveres for beslutning om GO/NoGO. Beslutning tas, arbeid avbrytes ved NoGO.g. Testsystemets database og søkefunksjonen tilpasses ny løsning, men søkefunksjonen går fortsatt mot de samme felter som før (Parameterbryter bør være lagt inn slik at man enkelt kan bytte mellom 'gammel type søk' til 'ny type søk'.)h. Testsystemets database®oppdateres med kvalitetssikrede data fra pkt e.i. Testing gjennomføres: Slå over søkerutinen (vha Parameterbryter) til å gå mot det korrigerte Fodt_Dato_Search feltet. Verifikasjonstester gjennomføres for å bekrefte at alt fungerer som forventet.j. Besluttning om overføring fra ProduksjonsTest database til Produksjons database avgjør når man 'går på lufta'. Ved NoGO avbryte etterfølgende punkter.k. Produksjonssystem oppdateres. Verifikasjon gjennomføres.l. Parameterbryter slås over permanent.Ved å gjennomføre pkt a. til d., får man en relativt rimelig en oversikt over kompleksitet og omfang, som grunnlag for kostnadsvurdering mht full gjennomføring. mvh Tore