For at kunne synkronisere de to databaser er du nødt til at definere, hvornår der er tale om samme person dvs. hvilk(e) felt(er), der skal matche, før du har et match. Det er derfor CPR-nummeret er så genialt, idet det identificerer hver enkelt på en entydig måde. Men det kan du jo ikke forlade dig på. Så hvad er dine muligheder?
Adresser er notorisk upræcise med mindre de er "renset" så alle gader har samme stavemåde og etager etc. har samme form. Men selv om du har adresserne på samme form, så kan det stadig være to forskellige personer, der blot deler adresse, men hvor den ene (for at bruge dit første eksempel) er med i skakklubben og den anden er med i løbeklubben.
Navne er også notorisk problematiske - for det første fordi mellemnavne til tider bruges som efternavne og Per Jones Hansen derfor kan stå som Per Jones eller Per J. Hansen eller Per Hansen eller Per Jones Hansen. For slet ikke at tale om to Per Hansener, der jo meget vel kan være to forskellige personer.
Det letteste er nok at lave en tabel i FileMaker, som har felter svarende til din import fra gmail. Herefter bygger du en relation mellem denne tabel og din egentlige database. Herefter kan du opbygge matchkriterier i flere niveauer afhængigt af, hvor entydigt de rammer. Et bud kunne være:
1) match på e-postadresse (match her er så godt som sikker succes)
2) match på navn og adresse (match her er er et godt bud)
3) match på navn og postnr (ikke helt god, men er der kun ét match går det nok)
4) match på navn (ikke helt gangbar)
osv.
For hvert matchkriterium opbygger du en separat relation i FileMakers relationsgraf. Du kan evt. vælge at lave nogle specielle versioner af felterne som beregnede felter hvor du fjerner alle tegn og mellemrum og laver alt om til små bogstaver. Derved undgår du, at adresserne "Store Gade 5" og "Storegade 5" ses som to forskellige adresser.
Du skriver ikke noget om telefonnumre, men de kan også være et godt bud - i takt med, at flere og flere har deres egen mobiltelefon er de også mere og mere unikke på samme måde som e-postadresser, som færre og færre deler mellem sig. Jeg vil betragte et match på mobilnummer som næste lige så godt som match på e-postadresse, og det gode ved tal er, at de ikke har samme muligheder for fejlstavning - der skal du blot fjerne mellemrum og enten fjerne eventuelle landepræfikser (+45 osv.) eller sætte landepræfikser på alle telefonnumre.
Herefter er der ikke andet for end at prøve at matche alle poster i database 1 mod base 2, og så må du vurdere, hvor langt ned i præcision, du vil gå, før du opgiver at matche og blot importerer posten fra base 1.
Hvis du har et match, men oplysningerne er forskellige i de to databaser, skal du også definere, hvilken database, du stoler mest på. Her ved du selv bedst, men hvis der er dato og tidspunkt for oprettelse og seneste ændring på posterne, bliver arbejdet lidt lettere.
Jeg vil anbefale dig, at du tildeler alle poster et unikt serienummer så du efterfølgende kan identificere hvilket serienummer i den ene base der matcher hvilket nummer i den anden base.
Din fremgangsmåde i øvrigt med at synkronisere op mod base 2 først og så skrive informationen tilbage giver god mening, men her må du igen have et felt at synkronisere op imod. Med mindre du blot vil slette base 1 og så importere alle poster fra base 2 (det vil jo være det letteste).
Der findes et værktøj fra Worldscyn - se
http://www.worldsync.com/ - til at synkronisere to FileMaker-baser, men det er nok ikke lige det, du har brug for.
Det var meget teori og ikke så meget praksis. Hvordan har du tænkt dig at køre importen? Skal det være et script, eller vil du selv ind over manuelt på dem med tvivlsomme match?
