Klokt beslut att stanna kvar med Disgen 8.2 jag gjorde likadant, har också betalt för Disgen 2016 som är oanvändbart för mig, om jag inte vill börja om från början och skriva in tusentals individer igen...
Klokt beslut att stanna kvar med Disgen 8.2 jag gjorde likadant, har också betalt för Disgen 2016 som är oanvändbart för mig, om jag inte vill börja om från början och skriva in tusentals individer igen...
Hur många som använder Disgen kan tänkas påverkas?
Dvs har en situation där de själva har länkat till en referens (individnummer) som inte längre finns.
Är man hjälpt av att få en korsreferenslista mellan gamla och nya id? Eller har ni förslag på någon annan enkel åtgärd?
Christer Gustavsson - Dis verksamhetsledare emeritus
Jag har pratat med de som kan programmering och de säger att det inte alls skulle var omöjligt att behålla de gamla individnumren. Men det är väl enkelt för nya medlemmar att börja med nya Disgen så varför ta hänsyn till os som troget har betalt in medlemsavgiften till DIS. Men det är enkelt att lämna DIS.
Det är väl bara att konstatera att en gedcom-export från Disgen2016 för att uppdatera en hemsida baserad på en gedcom-export från Disgen 8.2.d kvaddar hela siten.
Som DIS-medlem kan jag, baserat på frågan:
inte undgå att undra om DIS i den verksamhet som föreningen bedriver, med berått mod och avsiktligen bortser från de behov av bakåtkompatibilitetskaraktär som medlemmar, även om de är i minoritet, har.Ursprungligen postat av Christer
Precis vad som hände mig, så jag har gått tillbaks till Disgen 8.2.d igen, det var felköp att köpa Disgen 2016. Jag tog för givet att Disgen 2016 var bakåtkompatibelt, efter 42 år på SVT så kanske man tar en del saker för givet?
Jag är inne på samma linje, hur tänkte programmerarna på DIS?
Hur ska man som släktforskare komma med enkla åtgärder som en programmerare har gjort? Som släktforskare är man minst sagt dålig på programmering av släktforskningsprogram, åtminstone är jag det.
Kjell Arnesson det är vad jag försökt att få dom att förstå men där kör man huvudet i väggen.
Dom lever i sin egna lilla värd där inget får rucka deras intentioner. Hur man än förklarar hur
en dynamisk sida fungerar så blir det som goddag yxskaft.
Kan vi lyfta nivån lite. Jag försökte inbjuda till lite konkreta förslag på vad vi kan göra för att underlätta.
Jag har inte tidigare sett eller förstått att även GEDCOM är inblandat i sammanhanget.
Christer Gustavsson - Dis verksamhetsledare emeritus
Jag förstod nog inte dom konkreta förslagen?
Håller fullständigt med dig Bror Johansson. Dom är bara ute efter att vi som har en dynamisk sida för vår släktforskning skall lösa deras problem på för dom enklast möjliga sätt.
Hur svårt hade det varit att skapa en relationsdatabas där man kunde välja : Vill du behålla dina gamla ID-nummer? Så fungerar andra släktforskningsprogram. Och på frågan dom ställer "Hur många som använder Disgen kan tänkas påverkas"? Där kan bara gissa precis som vilken som helst. Har man intresse av att sälja en bra produkt så kan det generera hur många som helst som via mun mot mun metoden skulle vilja rekommendera DIS 2016. Men antagligen så fanns det ingen i den slutna kretsen av programvarutestare som hade en dynamisk hemsida. Därav uppstod detta problem. Gör om och gör rätt anser jag för att det skall bli någon succé.
Hur många gånger skall vi behöva förklara för att få dig att förstå det mest elementära i släktforskningsprogrammet DISGEN och andra likvärdiga program.
https://sv.wikipedia.org/wiki/GEDCOM
Så här skrev jag tidigare till dig 2016-04-25:
Leffe47 är uppkopplad nu
Leif Ellestad
Medlemsnr
41475
Inlägg
7
Så här är det i mitt fall Christer. Jag köpt en sida av en amerikan och hans sida kan du se här:
http://www.tngsitebuilding.com/
Den sida som jag har köpt och modifierat lite hittar du här:
http://www.ellestad.se/
Detta är alltså inte en vanlig exporterad html-sida från Disgen utan en dynamisk sida med en egen databas.
Alltså en sida med .php. Vad jag gör för att få denna sida att fungera är att jag genererar en Gedcom från Disgen 8.2 med alla noteringar. Alltså inga bilder eller annan media. Bilder på släktingar, kartor, gravstenar etc. laddar jag upp via en ftp klient i mitt fall FileZilla. Alla individer som jag för in i disgen tilldelas utan min inverkan ett ID-nummer. Och det är detta nummer som registreras via Gedcom-filen på min hemsida. På så sätt har jag följdaktligen satt ID-numret som ett prefix på alla min textdokument och foton i min släktforskningsmapp i min dator. Och då har jag fått en struktur på min forskning. Nu om jag på samma sätt med Disgen 2016 genererar en Gedcom-fil så blir alla individers ID-nummer ändrade i förhållande till Disgen 8.2. Och då om jag skulle ladda upp den Gedcom-filen till min sida så kommer sidan inte att fungera eftersom alla individers unika nummer inte längre stämmer. Min enda chans att kunna använda Disgen 2016 är om jag sätter mig ner och ändrar alla nya ID-nummer på mina dokument. Idag har jag 8.702 registrerade personer. Och eftersom varje individ har minst 3 dokument per skalle så blir det 26.106 ändringar. Jag har bara basflocken i Disgen 8.2. Hoppas att bilden klarnar.
Och du har fortfarande inte förstått vad en Gedcom-fil är.
Se även mitt inlägg ovan 2016-04-25 16:10.
I alla externa applikationer, som refererar till individnummer eller filnamn baserade på individnummer i Disgen 8, måste referenserna ändras eftersom individerna har fått andra individnummer i DG2016, var sig GEDCOM är inblandat eller inte! Det är inte mer komplicerat än så, men för många en allvarlig nackdel med att gå över till DG2016.
Kan det bero på att du och jag som har påbrå från Lycksele som gör att vi förstår problemet? :-)
Så kan det vara.
(Inlägg #32) Är man hjälpt av att få en korsreferenslista mellan gamla och nya id?
Ett annat förslag - skulle det hjälpa med en valmöjlighet vid gedcomexport från Disgen 2016 som, om man väljer den, medför att "individnumren" i gedcomfilen (dvs @Ixxxxxx@) istället konstrueras med hjälp av index och ev flocknr från den gamla databasen, om dessa nummer överfördes vid exporten? Alltså att "individnumren" i gedcomfilen skulle se ut som i 8.2 för de personer som fanns i den gamla databasen?
Ordförande & Disgenutvecklare.
Nja, jag vet inte om jag förstår dig rätt, om jag skall uppdatera Disgen 2016 vill jag att det id som personen har i Disgen 8.2 följer med till Disgen 2016, det du skriver ovan uppfattar jag som ännu en variant av nya id.
Idnumret följer med (om man väljer det vid konverteringen till Disgen 2016) men det hamnar i ett särskilt fält i databasen. Frågan nummer 2 i mitt tidigare inlägg gäller om det hjälper att det gamla idnumret används då gedcomfiler görs i Disgen 2016?
Exempelvis: en person med idnummer 123 i Disgen 8.2 exporterades i en gedcomfil som individ @I123@. Vid konverteringen till Disgen 2016 fick samma person ett nytt idnummer i den nya databasen, låt oss säga 4444. Vid gedcomexport från Disgen 2016 blir nu samma person identifierad som @I444@. Skulle det hjälpa om personen i stället vid gedcomexport identifierades som @I123@?
Det blev ganska tekniskt men det handlar om hur gedcomfilerna från en export i Disgen används av er som använder t ex TNG eller andra program.
Ordförande & Disgenutvecklare.
Var kommer I ifrån? Individ 123 exporteras till Disgen 2016 och ska ha ID NR 123 inga bokstäver framför, det finns väl inte i Disgen 8.2 ? Jag har inte sett bokstäver före ID NR förut i alla fall?
Varför ändrade man alla ID NR i Disgen 2016?
GEDCOM-exporten är bara ett specialfall av problemet. Det löser inte problemet för andra externa applikationer som baseras på individnumren i Disgen 8. I t.ex. mitt fall, och jag har sett andra som har gjort likadant, refererar jag till html-filer som genereras av html-exporten i Disgen. För att jag skall slippa ändra på mina referenser, borde alltså Disgen2016 generera html-filer med samma mapp- och filnamn som Disgen8 för samma individ. När man som jag bara har en flock, ser namngivningen av mappar och filer ut att vara individnumren rakt av ("modulo 1000"). Jag vet dock inte hur mapp- och filnamnsgivningen ser ut vid flera flockar. Av mina ca 8000 individer har jag dock referenser till kanske max 100 st så att ändra dem är väl överkomligt. Men det tar tid och det är lätt att introducera fel som måste letas upp och korrigeras.
Den generella lösningen vore att individnumren från Disgen8 överfördes som individnummer i Disgen2016 vid konverteringen.
(Hur genereras filnamnen vid html-exporten när man har flera flockar i Disgen8?)
"I" kommer från gedcom. När man exporterar till gedcom i Disgen (8.2 eller 2016) så används det interna individnumret med ett I framför. Det är ju gedcom som importeras till TNG, så därför tänkte jag att det kanske kunde hjälpa som jag skrev. Eftersom vi har uppdatering 1 nästan klar är det väsentligt att få reda på om det är något vi kan ändra nu innan den går ut. Men då kan det inte vara en stor ändring.
Av två skäl, väsentligen:
1) Vi gjorde om databasen från grunden.
2) Att ID-numren är synliga utifrån och skulle vara oföränderliga har aldrig vad jag vet varit dokumenterat - ett "löfte" så att säga - och använder man odokumenterade egenskaper kan det bli problem vid uppdateringar. Men låt oss spara politiken ett tag tills vi utrett om det finns något snabbt och riskfritt vi kan göra till uppdatering 1.
Ordförande & Disgenutvecklare.
For oss som bruker flokker eksporteres ikke Gedcom-id på det viset du angir.
Hos meg blir det f.eks.
0 @3-540@ INDI
1 SEX M
1 NAME Peder /Schjelderup/
1 BIRT
2 DATE 7 SEP 1571
2 PLAC Bergen, Hordaland
Det man kunne selvsagt gjort for å beholde individnr, var å bruke en tekstllig ID i stedet for en 32- bits integer, men vil jo da måtte formatteres som XXX_NNNNN (altså 999_99999) noe som jo vil ta 5 bytes mer plass i databasen enn en 4-bytes integer, som burde være tilstrekkelig for enhver slektsforsker om man ikke tar sikte på å lagre hele verdens befolkning som har levd siden Jesu tid :-) (Da trengs 64 bits tall evt. 128 bits presisjon :-D
(For dem som vil rydde litt opp i flokker før eksport kan man lage en kjøring i GEDtreff og få ut n plott av flokk vs tilstøtende flikker der n er antall flokker og et plott over alle flokkers forbindelser til ale andre flokker, og for hvert plott en oversikt over grensekryssinger, f.eks, person 1 er i flokk 1 mens ekteskapet er registrert i flokk 250
Pris? Et aktivt bidrag i DISBYT (status 5)
Alf Christophersen Disgen fadder Norge.
I Disgn 8 användes aldrig I respektive F för identiteterna i GEDCOM filerne, det är först nu i Disgen 2016 som den notationen kom till.
Här är du (och de andra) tyvärr ute på lite djupt vatten eftersom DIS vad jag vet aldrig lovat att sådana mapp- och foldernamn ska vara oförändrade från version till version. Minns jag inte fel, så ändrades detta från 8.1 till 8.2, och nu med Disgen 2016 ändras det igen. Det går inte att förutsätta att det ska vara oförändrat från version till version. Detta kan mycket väl ändras igen i framtiden.
Den generella lösningen vore nog att ha en unik identifierare för varje individ i Disgen, som garanteras vara densamma oberoende av Disgenversion. Detta har vi alltså inte idag. En del program använder ett stort slumptal för detta (en sk. UUID) och det tror jag är en bra lösning. Sedan skulle man exempelvis kunna göra en referenstabell från identifieraren till den genererade HTML-sidan som skulle hanteras av en databas på serversidan, men hur man än vänder sig här blir det en mer avancerad lösning för den som vill göra sina egna lösningar som är mer avancerad än de HTML-sidor som Disgen kan leverera idag.
Men med all respekt för er som åker på merarbete nu när vi ändrat i Disgen - hur kan vi komma överens om en gränsyta i Disgen som inte ändras i framtiden, så att de som vill kan göra en bättre webbpresentation än den Disgen tillhandahåller idag?
Ordförande & Disgenutvecklare.
Eksemplet mitt ovenfor er fra Disgen 8.2d, så endringen er vel kun for flokk 0 (kanskje begrenset til at bare flokk 0 er i bruk?)
Alf Christophersen Disgen fadder Norge.
Et slumptall er drepen om man bidrar med flere bidrag i disbyt, eller oppdaterer feil, og får dubletter, men med forskjellige nr, og man får nekrofile resultater. F.eks. en person gift med sin forlengst avdøde tipptipptipp oldemor :-D
Alf Christophersen Disgen fadder Norge.
Jag kan - även om jag av olika skäl egentligen inte aktivt vill diskutera Disgennära företeelser - kortfattat beröra hur jag hanterade motsvarande situation då jag migrerade mina Disgen8.2-data till MySQL-data.
Individerna i MySQL-databasen gavs såväl en DisgenID-kolumn som en "auto-increment"-kolumn. Båda dessa kolumner bidrar till en "composite primary key" för individen i fråga. För "nya" individer låter jag DisgenID få ett konstant och diskriminerande värde som inte kan förekomma i 8.2. De båda kolumnernas domäner är disjunkta.
Det primära skälet till att låta DisgenID finnas kvar i MySQL-databasen var att jag - i likhet med vad som är fallet för åtminstone några andra släktforskare - använt detta ID för "egna" syften.
Jag är nöjd med min lösning (som fungerar).
Jo då, Daniel, jag var fullt medveten om att jag använde mig av en odokumenterad sak i Disgen. Jag tycker dock att det är synd att Disgen-programmerarna inte har kunnat förutse sådana externa applikationer. Att döma av den här tråden är jag inte ensam om detta.
Behörigheter för att posta
Svara med citat