Zit es te turen naar de Roze dump van Foondump versie 4.10 …
In de door Foondump geleverde pink_subscriber-tabel staat bijvoorbeeld deze vermelding:
[i](AAH) Accountants Adviesbureau Houweling
St. Ignatiusstraat 263
4817 KK Breda
076-5300848[/i]
Met het zoekprogramma in het Roze gedeelte van de CD-foon krijg je hem ook maar nu met een post-adres en een faxnummer erbij:
[i](AAH) Accountants Adviesbureau Houweling
St. Ignatiusstraat 263
4817 KK Breda
(076) 530 08 48
Postbus 9380 4801 LJ Breda
fax 076 5300192[/i]
Deze gegevens staan wel in mijn Foondump-tabellen ‘pink_info’ en ‘_phonenumbers’ maar alleen als ‘orphans’.
Het zijn verweesde records zonder link - dus zonder een overeenkomstige ‘id’ - naar mijn tabel ‘_subscriber’.
Bij nader onderzoek blijken er in mijn Roze dump meer dan 75.000 ‘_phonenumber’-records te staan die ik niet thuis kan brengen en idem een veelvoud daarvan in de ‘_info’-tabel.
Foondump-team, hoe zat het ook alweer, zijn dit gegevens die die bij weggelaten dubbele vermeldingen horen?
Ik heb wel een lege pink_unique tabel waar ik tijdens het dumpen de md5 keys in zie langs komen maar die is na afloop weer leeg.
Waar gaat dit fout? Een hoop faxnummers en dergelijke missen zo de boot.
Het was nog erger, alle info en phonenumber records waren verschoven. Bij subscriber record x hoorde info record x+1.
Super dat jullie deze fout er uit gehaald hebben —)
Even de discussie over Database pakketen vervolgen:
DB2 heeft tools die de referentiele integriteit kunnen checken. Hij analyseert de huidige database. Daarna een unload en als je de nieuwe database load dan ziet hij dat er verschillen in zitten. Als beide dump programma’s geen goede database referentie hebben dan zal hij dat natuurlijk niet opvallen.
Referentiele integriteit is iets heel anders dan een verschuiving van records. Dit zat niet op het niveau van de tabelstructuren, dit zat op niveau van de data zelf.
PS We hadden helemaal geen ‘discussie over database pakketten’, deze thread ging over een bug.
In de lege Access db die meekomt met Foonddump zou je ‘Enforce Referential Integrity’ kunnen aanzetten. De kolom met subscriber id’s moet je daarvoor wel op uniek zetten.
Jan Marco heeft het dan in zoverre bij het rechte eind dat alle phonenumber- en info-record’s met verschoven id’s geweigerd worden als die id’s niet voorkomen in subscriber, Access zou waarschuwen.
Daarentegen, foute records die toevallig een id hebben die wel voorkomt in subscriber zal Access blij aanpakken. Je had het probleem misschien eerder ontdekt maar Referential Integrity was hier niet afdoende geweest.