’t Is altijd iets. Een mens probeert zijn database zo vendor-unspecific mogelijk te maken, zonder triggers of cascading deletes of dingen, zodat ze zowel in pakweg Oracle als SQL Server als Access kan werken. Het gevolg neem ik er dan wel bij, dat de applicatie een hoop meer moet doen.

Een tabel met een trigger op insert van het genre

create trigger nieuwDinges on tblDing for insert as select ID from inserted

..dat niet echt véél gemakkelijker dan eerst een uuid te maken, en die dan te gebruiken voor allerlei inserts en updates, maar aan de delete-kant is het toch soms een ander paar mouwen.

Bij het vervangen van een volledig nieuwe reeks producten, waar geen consistente keys zijn en ik dus geen selectieve insert/update/delete voor kan verzinnen, moet ik hier alles van één bepaald producttype verwijderen.

Dat wil dus zeggen: eerst het prodType_ID achterhalen, dan alles uit tblProducts van dat producttype halen, en voor elk product een delete doen van het overeenstemmend record uit tblObjects. En, dat is het net, ik was helemaal uit het oog verloren dat daar nog een metabase aan vasthangt. Dus moet ik ook alle tblProddataSTC, tblProddataNUM, tblProddataBIT en zooi wegkieperen. En aangezien de records in tblProddataSTC nog eens stringcodes zijn die doorverwijzen naar tblTrans, moet daar ook allerlei uit weg.

En dàt zou een hoop simpeler geweest zijn met een aantal propere triggers op delete. Of met cascading deletes (naar eigen voorkeur natuurlijk).

Oh well. ’t Is niet precies raketwetenschap, dus ’t is rap gedaan. En gelukkig had ik alleen nog maar op de staging site zitten werken, anders was de hoofddatabase heeltegans vervuild geraakt (en met 127.000 teksten in de tblTrans-tabel is het al groot genoeg gelijk het nu is).