[mssql] trigger for alter?

[_Thanatos_]

Ik heb weer wat hoor
Ik heb een formulier gemaakt in ASP dat dynamisch gegenereerd wordt uit een tabel. Alles goed en wel, het werkt perfect. Nu komt het probleem: voordat het formulier gegenereerd wordt, moet er wat validatie plaatsvinden. Als het formulier valid is, wil ik dat graag in de database opslaan, met een "bit" veld. Dat is ook gelukt.

En nu het echte probleem
Als het design van de tabel verandert, moet automatisch dat "bit" veld op 0 gezet worden, zodat de ASP code ziet dat het formulier opnieuw gevalideerd moet worden.

Maar hoe
Ik weet best dat een "trigger for alter" niet kan in mssql, maar is er misschien een truuk om zoiets op een andere manier op te lossen?

[Verwijderd]

trigger on update zetten?

[_Thanatos_]

Helaas, het gaat echt om een stuk sql dat uitgevoerd wordt, wanneer er velden in de tabel veranderen, dus niet de data zelf. als je een trigger for update gebruikt, wordt ie toch niet uitgevoerd wanneer je enkel een veldje aan je tabel toevoegd? (of een veldje hernoemt, of verwijdert, of datatype verandert)

Ik moet zeggen dat ik niet zoveel ervaring heb met triggers, maar ik zal het wel ff proberen.

*probeer* nee, ik maak een trigger for update, voeg een veldje toe, en de trigger wordt vervolgens niet uitgevoerd...

[cameodski]

Wie doen die tabelwijzigingen? Het is toch een kleine moeite om na zo'n wijziging even een UPDATE uit te voeren, waarmee dat bit veld weer op 0 gezet wordt.
Overigens kun je als je wil filteren op dat bit veld er misschien beter een tinyint van maken en hier vervolgens een index op leggen. Dat zoekt waarschijnlijk iets sneller. En op een bit kun je nu eenmaal geen index leggen.

[Verwijderd]

Ok.. iets duidelijker trigger op update van syscolumns...

[_Thanatos_]

Yarvieh, iedere programmeur zou dat kunnen doen, maar het ging me erom dat het iets is dat je gewoon niet mag vergeten. En dan automatiseer je het dus. Maar wat je zegt, dat is helemaal geen gek id. Ik hoop dat dat kan (als in, er zijn meer dingen die je met system tables niet mag). Als ik morgenochtend weer op me werken, ga ik het gelijk uitproberen, bedankt iig alvast

cameodski, we hebben op me werk een sql-expert rondlopen en zal het ns aan hem vragen hoe dat zit met indices/bits/tinyints. Kzal het antwoord enzo hier wel weer posten.

[Annie]

Dat je niet zomaar aan system tables mag rommelen is natuurlijk niet voor niets, dus bezint eer ge begint (and plz make backups).
Bij mijn weten is het overigens niet mogelijk om triggers te plaatsen op system tables, maar als het dan wel mogelijk is houdt er dan rekening mee dat bij elke update van je server (bijv. service packs) er een mogelijkheid is dat je trigger niet meer doet wat 'ie moet doen.

_Thanatos_ schreef op 05 november 2002 @ 20:02:
...we hebben op me werk een sql-expert rondlopen...

Dan had je hem deze vraag toch ook kunnen stellen

[_Thanatos_]

Dan had je hem deze vraag toch ook kunnen stellen

nee, want hij is er niet elke dag, hij is met een groot project bezig en is waanzinnig duur (gedetacheerd). Maar ik zal weleens vragen wat hij erop te zeggen heeft

[cameodski]

_Thanatos_ schreef op 05 november 2002 @ 20:02:
cameodski, we hebben op me werk een sql-expert rondlopen en zal het ns aan hem vragen hoe dat zit met indices/bits/tinyints. Kzal het antwoord enzo hier wel weer posten.

Laat me raden. Hij gaat hetzelfde zeggen als wat ik al gezegd heb.
Of wilde je soms nog meer weten?

En zoals Annie al aangeeft, is het inderdaad niet mogelijk om triggers aan te maken voor system tabellen.

Wat eventueel nog wel een optie is om een job aan te maken die regelmatig controleert mbv een query of de structuur nog steeds hetzelfde is.

Maar het beste is en blijft om ervoor te zorgen dat degene die tabel mag wijzigen ook weet dat dan dat bitje op 0 gezet moet worden.

* cameodski vraag zich overigens af of het wel logisch is om na elke tabelwijziging alles opnieuw te valideren.

[maikel]

Waarom zou de databasestructuur nog veranderen ?
Naar mijn weten klopt er toch iets niet als die regelmatig verandert hoor. Na een wijziging in de databasestructuur moet je toch ook al je code gaan wijzigen ?

[_Thanatos_]

Waarom zou de databasestructuur nog veranderen ?

Waarom niet?

Het systeem is niet voor mezelf, het is voor klanten gebouwd. Als een klant een veldje erbij wil, dan moet dat kunnen.

[kvdveer]

_Thanatos_ schreef op 06 november 2002 @ 01:16:
Het systeem is niet voor mezelf, het is voor klanten gebouwd. Als een klant een veldje erbij wil, dan moet dat kunnen.

Dat is echt fundamenteel fout design... Als de klant er een veldje bij wil betekent dat dat je vooronderzoek niet goed hebt uitgevoerd.
Als na een goed vooronderzoek de klant iets wil dan vraag je daar netjes geld voor, en krijg je dat ook. VOor dat geld kun je prima die ASP pagina's aanpassen.

[Crazy D]

Onder het mom van "de klant moet eigen velden kunnen toevoegen" kan ik me voorstellen dat ze een veldje toevoegen (en das beter dan alvast 10 bit velden, 10 varchar velden, etc aanmaken "voor het geval dat").
Hoe maakt de klant dat extra veld aan? Als ze dat via de enterprise manager doen, moeten ze zelf ook maar zorgen dat het veld de default waarde krijgt Ik zou persoonlijk, als het noodzakelijk is dat klanten eigen velden kunnen toevoegen, daar ook een interface voor schrijven, en daar kun je dan direct de tabel updaten.

[maikel]

Je zou ook een aparte tabel kunnen maken met 2 kolommen: veldnaam, waarde.
Die kun je dan koppelen aan de klant.
Zo voegt de klant ipv een kolom, alleen maar een rij toe.
Misschien moet je toch nog eens naar je design kijken hoor. Een database waarbij de klant nog kolommen kan toevoegen is nooit goed.

[Goodielover]

Heeft de systeemtabel niet een datetime veld dat je kan vergelijken met je bitje. Dan maak je dus van het bit-veld ook een datetime veld. Het bitje (wel/niet genereren) leid je dan af de vergelijking van die twee datetimes.
Duidelijk?

[_Thanatos_]

De klant voegt niet zelf een veldje in de EM toe
Zo'n meneer/mevrouw belt ons op van "ik wil graag dat en dat veld erbij en dat en dat moet erin mogen." De rest regelen wij dan.

En helaas geen datimetime veld in de syscolumns zo te zien. Een trigger erop zetten mag ook niet van mssql.

[Goodielover]

Is er geen andere eigenschap in de syscolumns die je kan sommeren oid, bijvoorbeeld byte-grootte, dan kan je een redelijk vertrouwd beeld krijgen. (Voordat er allerlei reactie hierop ontstaan, theoretisch is dit niet waterdicht, praktisch 98% schat ik in)

Hoe ga je om met wijzigingen in de business rules. Waar leg je die vast? Komen die wijzigingen niet veel vaker voor dan DB-structuur wijzigingen?

[Crazy D]

_Thanatos_ schreef op 06 november 2002 @ 10:48:
De klant voegt niet zelf een veldje in de EM toe
Zo'n meneer/mevrouw belt ons op van "ik wil graag dat en dat veld erbij en dat en dat moet erin mogen." De rest regelen wij dan.

Dan snap ik het probleem niet zo. Jullie moeten er dan toch heen, of op afstand, of met een scriptje, oid, om dat veld toe te voegen. Dan kun je toch meteen die default waardes vullen? (en desnoods maak je een scriptje die de alter table query maakt, en die laat je ook meteen de update query genereren).