Surprise! Your records are toast!

[Joris Aarts]

Hello,

 

Vandaag een verrassende ontdekking gedaan in FileMaker 7/8.

 

Het gaat over de optie 'Delete related records in this table when a record is deleted in the other table' oftewel de 'cascade delete' optie.

Ten eerste kan je de die optie telkens opnieuw aanvinken tussen verschillende Table Occurrences (TO's) die gebaseerd zijn op dezelfde Base Table. Dat wekt de valse indruk dat je dat afzonderlijk per TO kan instellen. NOT! Van zodra je ergens in je relatiediagram aanvinkt, geldt die voor ALLE TO's. Met andere woorden: je related records zijn sowieso foetsie.

Bon, daar konden we mee leven en de FM help waarschuwt daar in zekere zin ook voor met de onheilspellende woorden: 'This option deletes related records even when you're browsing a layout that doesn't display the related records.'

 

Nu ontdekte ik vandaag tot mijn grote verbazing dat de related records OOK verdwijnen als je in een ANDER bestand via een file reference de optie 'delete' aanvinkt en in het ORIGINELE bestand een parent record verwijderd. Dus je kan perfect een file hebben waar er geen delete gebeurd. Dan een andere file openen met een reference waar de delete wél aanstaat. Vanaf dan gedraagt je originele file zich niet meer als vroeger maar begint-ie related records te deleten. (Voorbeeldje in bijlage: zolang test2 niet openstaat gedraagt test1 zich normaal. Open test2, ga terug naar test 1 en verwijder een record....)

 

Quite shocking, no? Als dit nog expected behaviour is, dan vind ik het wel het randje. Hoe ga je in godsnaam zoiets managen/documenteren in een groter project? Even de knuppel in het hoenderhok smijten: plots lijkt Access een heel eenvoudig programma...

 

Veel groeten,

 

Joris

CascadeDelete.zip

[AvD]

Da's dus het tweede vandaag...

[AvD]

En om op je probleemstelling te antwoorden: ik heb die cascade delete altijd als een potentiële ramp beschouwd, en daarom ook NOOIT verwerkt in solutions die door anderen moesten gebruikt worden. Als er dan toch behoefte was tot zo'n delete-type, dan gebeurde dat telkens via scripting met de nodige waarschuwingen.

Dit is een belangrijke veiligheid, zeker nu we sinds vandaag weten dat 2 * 4 soms 7 is (zie hier maar even...).

[Joris Aarts]

Hoi,

 

ik heb die cascade delete altijd als een potentiële ramp beschouwd, en daarom ook NOOIT verwerkt in solutions die door anderen moesten gebruikt worden

 

Hmm, AvD, heb jij een zwarte lijst van features die NOOIT in solutions verwerkt mogen worden? Is dat een lange?

Ik bedoel: nu we weten hoe het exact werkt kunnen we er wel weer mee leven... en er misschien nog eens ons voordeel mee doen...

Ik ga wel akkoord met je stelling dat je meer controle hebt als je complexe delete operaties inkapselt in scripts. Maar eigenlijk zou er ook zoiets als een centrale basisbescherming op data-niveau moeten zijn.

 

FileMaker wil het laten lijken alsof ze referentiële integriteit integreren in FileMaker 7/8 (zie ook 'Using FileMaker Pro 8', Scott Love e.a..) Maar in feite creëren ze een gigantische valkuil, want je kan dus nergens op centraal, structureel niveau (zonder scripts) de integriteit van je data waarborgen, zoals dat wel kan...

 

Veel groeten,

Joris

[AvD]

heb jij een zwarte lijst van features die NOOIT in solutions verwerkt mogen worden?

Niet echt, nee, maar wel een eigenschap die we "beduchtheid" of "bedachtzaamheid" zouden kunnen noemen, om niet te zeggen "argwaan". Ik heb vroeger eens geleerd dat er niets dramatischer is voor data dan "delete". Dat is altijd goed bijgebleven (vandaar de radio buttons Actueel Ja/Nee op zo goed als elke record. Gewoon een kwestie dus van "niet vertrouwen". Maar zoals je ondertussen al wel zal weten, ook dat helpt niet altijd... (zie hierboven).

[SuperWimmie]

....ik heb die cascade delete altijd als een potentiële ramp beschouwd, en daarom ook NOOIT verwerkt in solutions die door anderen moesten gebruikt worden.....

 

Hhhhmmmm, ik wil er juist vanuit kunnen gaan dat de database zo veel mogelijk zelf zijn integriteit waarborgt...

Dus zorgen we voor een heldere structuur qua verzamelingen en verhoudingen. In versie 6 lukt ons dat steeds en uit ervaring blijkt dit erg goed te werken. Geen "weesjes" in de records te vinden!

 

 

 

* zucht *, we gaan weer testen...

(Filemaker wordt duur vanwege het testen, programmeren wordt inderdaad stukken goedkoper)