[T-SQL] SP uitvoeren vanuit trigger *

[Verwijderd]

Ik heb een leuke uitdaging voor een beginnende sql programmeur zoals ik...

Ik heb een aantal stored procedures geschreven die ieder 'iets' uit de database controleren.

Ik wil deze sp's aanroepen via een trigger op het moment dat er een wijziging in een tabel plaatsvindt. Ik gebruik sql server 2000. De trigger activeert dan de stored procedures en afhankelijk van het resultaat hiervan wil ik één veld in dezelfde tabel updaten met een statuscode.

Volgens mij moet de opbouw van de trigger er zo uitzien:


CREATE TRIGGER MyTrigger ON [dbo].[TService]
after insert, update
AS
declare @row_id varchar(4), @owner_type varchar(10)

execute sp_Rule1(@row_id);
execute sp_Rule2;
/* etc, nog een paar sp's */


Wat me hierin al niet lukt is het doorgeven van de parameters. Bijvoorbeeld sp_Rule1 ziet er als volgt uit:


CREATE PROCEDURE dbo.sp_Rule1

@row_id varchar(10)
as

begin
SELECT count(*) FROM Table1 Where (Table1.ID = @row_id) AND (Table2.Type = 1);
end
GO


Oftewel, @row_id moet worden meegegeven aan sp_Rule1. De waarde hiervan is gelijk aan het record dat in de tabel wordt geupdated. Hoe doe je dit???

Daarna heb ik nog een tweede probleem .. oh nee.. uitdaging

Er moet een soort if-statement om ieder 'execute sp_Rule_x' procedure heen. Afhankelijk van het resultaat van de sp, wil ik graag nog een veldje updaten in dezelfde tabel met daarin een tekstberichtje (als toelichting op de statuscode).

Wat ik vind op het web is dat de inhoud van de stored procedures gelijk in de triggers worden geschreven. Niet alleen wordt de triggercode dan erg groot, maar ik vind het juist wel netjes gescheiden zo. Maar als het niet mogelijk is op deze manier dan hoor ik dat ook graag...

P.S. ik word helemaal gestoord van die verschillende SQL-dialecten!!!

[whoami]

De records die door de trigger worden geupdated, kan je terugvinden in de 'updated' 'inserted' temporary table.

code:

SELECT blaat FROM inserted

hmmm....
Ik twijfel nu of die temp. table updated of inserted heet....
Het is dus inserted.

De return code van de SP kan je zo opvragen:

code:

declare  @return_waarde INT
declare @param1 VARCHAR(20);

SELECT @param1 = 'blaat'

EXEC @return_waarde = MyStoredProcedure @param1

Owja, het is beter dat je je naam van je stored procedure niet met SP laat beginnen.
SQL Server denkt dan nl. dat het om een system-sp gaat, en gaat dan eerst de stored procedure in de MASTER db gaan opzoeken, waardoor het geheel natuurlijk wat trager gaat.

[ Voor 46% gewijzigd door whoami op 20-10-2003 16:26 ]

[faabman]

is je @row_id een varchar??? (neem aan dat dat niet ook je identity is)

en waarom wil je de toelichten van de statuscode in de insert / update meenemen?? daarvoor heb je toch een relationele database?? als je de beschrijving wil zien dan moet je gewoon een view aanmaken die hem...

voor de rest kan ik je aanraden om op www.sqlteam.com te kijken
of ff te zoeken op google

[ Voor 6% gewijzigd door faabman op 20-10-2003 16:26 ]

[P_de_B]

offtopic:
>>> Owja, het is beter dat je je naam van je stored procedure niet met SP laat beginnen

dit moet zijn sp_ (dus: sp underscore)

[whoami]

P_de_B schreef op 20 October 2003 @ 16:33:

offtopic:
>>> Owja, het is beter dat je je naam van je stored procedure niet met SP laat beginnen

dit moet zijn sp_ (dus: sp underscore)

Yep, inderdaad.
mierenneuker.

[P_de_B]

mierenneuker.

I know, I know

[Verwijderd]

Ok, dank voor de suggesties. Als ik het zo maak:

code:

CREATE TRIGGER Test ON [dbo].[TTabel] 
after insert, update 
AS

declare @return_waarde INT
SELECT ColumnID FROM inserted

SELECT @return_waarde = 'ColumnID'

EXEC @return_waarde = sp_Rule1 @return_waarde
update TTabel set TestField = 'gelukt' Where TTabel.ColumnID = @return_waarde

In ieder geval wordt de trigger volgens mij wel uitgevoerd, dat is al een overwinning.

Wat er gebeurt er... stel ik voeg zelf een nieuw record toe. Als ik het record verlaat en deze dus ge-inserted wordt, zou de trigger moeten gaan.. is het niet?

Als ik de tabel sluit en ik open em weer... dan is mijn nieuwe record verdwenen! Als ik de trigger verwijder en ik doe hetzelfde, blijft een nieuw record wel staan... ra ra hoe kan dat?!

[ Voor 3% gewijzigd door whoami op 23-10-2003 09:13 ]

[whoami]

Maak je gebruik van een transactie, en ga je die transactie nergens gaan committen?

PS: maak ook gebruik van code-tags.

Ik snap ook niet goed wat je hiermee wilt bereiken:

code:

SELECT ColumnID FROM inserted

SELECT @return_waarde = 'ColumnID'

Wil je hier niet:

code:

SELECT @return_waarde = ColumnId FROM inserted

doen?

[ Voor 69% gewijzigd door whoami op 23-10-2003 09:14 ]

[Crazy D]

P_de_B schreef op 20 October 2003 @ 16:33:

offtopic:
>>> Owja, het is beter dat je je naam van je stored procedure niet met SP laat beginnen

dit moet zijn sp_ (dus: sp underscore)

offtopic:
Dat staat ook in Books Online, maar als je gaat kijken, beginnen juist alle system stored procedures met sp_ ... (en dat was het argument om stored procs namen niet met sp te laten beginnen...)

[Verwijderd]

Reactie op whoami.

Je hebt gelijk, dat klopte niet. Inmiddels ben ik een stukje verder... ik zou bijna zeggen dat het leuk begint te worden

Het ziet er nu zo uit:

code:

CREATE TRIGGER Test ON dbo.TService 
after insert, update 
AS
BEGIN
declare  @return_waarde int;
declare @param1 varchar(20);
declare @results varchar(20); 

SELECT @return_waarde = ServiceID FROM inserted
EXEC @param1 = sp_BeginOfProcessObject_rule1 @return_waarde

if @param1 = 1 BEGIN
    update TService set Status = @param1  Where TService.ServiceID = @return_waarde
              END
END

Probleem hier is dat @param1 niet de waarde heeft die de sp_... teruggeeft. Binnen deze sp heb ik het volgende statement staan:

code:

@row_id varchar(10) output

maar ik zie dat @param1 de waarde nul heeft. Terwijl de uitkomst van de sp 1 is (getest in Query Analyzer).

[whoami]

Een return waarde is niet hetzelfde als een output-parameter.

Een return - waarde geef je terug dmv een RETURN statement in je stored procedure:

code:

CREATE PROCEDURE test
AS
BEGIN
   RETURN 1
END

en lees je als volgt uit:

code:

DECLARE @ret_val INT
EXEC @ret_val = Test

Een output-parameter gebruik je zo:

code:

CREATE PROCEDURE test ( @p_param INT OUT)
AS
BEGIN
  SELECT @p_param = 1
END

code:

DECLARE @blaat INT
EXEC Test @blaat OUT

_{mind eventuele syntax errors}

[Verwijderd]

Ok, nu begin ik er weer hoe langer hoe minder van te snappen.

Ik moet een variabele tussen procedures doorgeven... dat zou toch moeten lukken one way or the other.

Wat niet duidelijk is, is hoe ik het resultaat van een stored procedure opsla(at) in een variabele.

De stored procedure ziet er nu zo uit:

code:

CREATE PROCEDURE dbo.sp_BeginOfProcessObject_rule1

@row_id varchar(10)
as

begin
  SELECT count(*) FROM bla etc etc.... 
end
GO

Wat moet hieraan worden toegepast zodat het resultaat van het select statement in een variabele komt te staan?

[whoami]

Kijk nog eens goed in die code-voorbeeldjes die ik net gepost heb....
Daar doe ik dat oa.

code:

SELECT @variabele = count(*) ...

dus

[Verwijderd]

Ok dan, dat heb ik nu ook (ik had niet door dat SELECT @p_param = 1
een volwaardig select statement is).

code:

CREATE PROCEDURE dbo.sp_BeginOfProcessObject_rule1 (@result varchar(20) out)

as
declare @row_id varchar(10);

begin
  SELECT @result = count(*) FROM bla etc etc...
end
GO

Die is akkoord toch?

Als ik deze dan aanroep vanuit mijn trigger, volgens jouw voorbeeld zou het er zo uit moeten zien als ik alles goed heb begrepen :

code:

CREATE TRIGGER Test ON dbo.TService 
after insert, update 
AS
BEGIN
declare @return_waarde int;
declare @param1 varchar(20);

SELECT @return_waarde = ServiceID FROM inserted
EXEC  sp_BeginOfProcessObject_rule1 @return_waarde, @param1 out

if @param1 = 1 BEGIN
update TService set Status = @param1  Where TService.ServiceID = @return_waarde
END
END

Voor sp_BeginOfProcessObject_rule1 is @return_waarde als input parameter vereist. @param1 moet gevuld worden met de waarde uit @resut.

Alleen dan krijg ik een foutmelding dat er twee parameters worden meegegeven terwijl er maar één wordt verwacht.

[whoami]

Tja, logisch.
Je procedure neemt maar 1 parameter, en jij geeft er 2 mee.

Trouwens, count() returned altijd een numerieke waarde, waarom ga je die dan in een varchar gaan proppen?

[ Voor 43% gewijzigd door whoami op 23-10-2003 12:29 ]

[Verwijderd]

Ik vroeg hoe je het doorgeven van een variabele uit een sp naar de trigger uitvoert.

En nu zeg je dat ik er 2 meegeef vanuit de trigger naar de stored procedure.

Dat klinkt erg tegenstrijdig.... waarvoor gebruik je anders de toevoeging 'out'.

Ik heb wel gezien dat jouw voorbeeldje sec wel werkt, jij weet dus wel hoe het werkt.

Misschien moet ik het dan anders formuleren. Hoe pas ik jouw voorbeeldje aan zodat ik ook een input parameter kan gebruiken die de stored procedure nodig heeft om te kunnen runnen.

whoami schreef op 23 October 2003 @ 12:27:
Tja, logisch.
Je procedure neemt maar 1 parameter, en jij geeft er 2 mee.

Trouwens, count() returned altijd een numerieke waarde, waarom ga je die dan in een varchar gaan proppen?

[whoami]

[nohtml]

Verwijderd schreef op 23 October 2003 @ 13:43:
Ik vroeg hoe je het doorgeven van een variabele uit een sp naar de trigger uitvoert.

En nu zeg je dat ik er 2 meegeef vanuit de trigger naar de stored procedure.

En dat doe je:

code:

EXEC sp_blaat @param, @param OUT

Dat klinkt erg tegenstrijdig.... waarvoor gebruik je anders de toevoeging 'out'.

Omdat je daarmee een OUTPUT parameter definieert.
Echter, die OUTPUT parameter moet je ook in je SP definieren, en als je je SP aanroept, moet je die parameter ook meegeven.
Lees anders eens iets in de Books Online over Stored Procedures.

Misschien moet ik het dan anders formuleren. Hoe pas ik jouw voorbeeldje aan zodat ik ook een input parameter kan gebruiken die de stored procedure nodig heeft om te kunnen runnen.

Als je met output parameters wilt werken, heb je een parameter nodig die je als OUTPUT parameter definieert.
Waarschijnlijk kan je een parameter zowel als input als als output paramter gebruiken.

code:

CREATE PROCEDURE blaat ( @p_Param INT OUT )
AS
BEGIN
  
  SELECT @p_Param = count(*) from tabel WHERE id = @p_Param
   
END

code:

DECLARE @var INT
SET @var = 1
EXEC blaat @var

Ik weet dus wel niet of bovenstaand voorbeeld zal werken.
Of anders doe je het mbhv die RETURN waarde.

[ Voor 11% gewijzigd door whoami op 23-10-2003 13:56 ]

[Verwijderd]

Nou misschien moet ik het dan maar aan een andere lezer vragen, want ik word niet wijzer van jouw uitleg.

Voor mij is leren het zien van goede voorbeelden om te snappen hoe de mechanismes werken. Nu ben ik alleen maar aan het prutsen en stijgt mijn stress-factor tot ontoelaatbaar niveau.

En het draadje is ondertussen veel langer dan noodzakelijk.

Mijn vraag is (behalve voor mij) denk ik niet zo moeilijk:

Ik heb een trigger die een stored procedure aanroept. De stored procedure heeft een waarde vanuit de trigger nodig om te kunnen runnen. Het resultaat van de stored procedure moet als variabele worden teruggegeven aan de trigger (omdat ik er daar nog een if then else omheen wil bouwen).

Ik ga die books online doorlezen (waar vind ik die overigens).

Als iemand ook nog een tip heeft voor een goed boek over SQL voor MS SQl Server 2000 houd ik me zeer aanbevolen.

[whoami]

[nohtml]

Verwijderd schreef op 23 October 2003 @ 14:06:
Nou misschien moet ik het dan maar aan een andere lezer vragen, want ik word niet wijzer van jouw uitleg.

Voor mij is leren het zien van goede voorbeelden om te snappen hoe de mechanismes werken. Nu ben ik alleen maar aan het prutsen en stijgt mijn stress-factor tot ontoelaatbaar niveau.

Owja, ik zit hier m'n tijd in te steken, maak voorbeeldjes, en dan begint meneer te stressen?
Ga ff wat anders doen, en lees dan die replies nog eens, en anders zoek je het ff op in de BoL ofzo.

En het draadje is ondertussen veel langer dan noodzakelijk.

Kan ik er aan doen dat je het niet snapt?

Ik heb een trigger die een stored procedure aanroept. De stored procedure heeft een waarde vanuit de trigger nodig om te kunnen runnen. Het resultaat van de stored procedure moet als variabele worden teruggegeven aan de trigger (omdat ik er daar nog een if then else omheen wil bouwen).

Nogmaals, lees die replies nog eens.

[Xboty]

whoami schreef op 23 October 2003 @ 14:53:
[nohtml]


Owja, ik zit hier m'n tijd in te steken, maak voorbeeldjes, en dan begint meneer te stressen?
Ga ff wat anders doen, en lees dan die replies nog eens, en anders zoek je het ff op in de BoL ofzo.

hmm rustig maar

[Verwijderd]

Je antwoorden hebben me zeker geholpen... ik ben tenslotte een stuk verder dan vanochtend, ik kan het alleen niet verkroppen dat jouw voorbeeld opeens niet meer werkt op het moment dat ik er nog een variabele bij stop.

Ik ben de hele dag alleen maar hier mee bezig en krijg het domweg niet voor elkaar. Dat is voor mij het frustrerende aan dit soort IT-geneuzel. Sommige kleine dingetjes kosten waanzinnig veel tijd... 't ergste is dat het inderdaad komt omdat ik het niet snap.

Dat was, is en zal de eeuwige ellende van IT blijven vrees ik.

Ik heb je voorbeeldje vele malen doorgenomen en ik kom er niet aan uit hoe dit te doen met een extra parameter. Ik ben dan ook begonnen met andere wegen te zoeken (qua informatiebronnen dan), want anders blijf ik in deze loop zitten.

Xboty schreef op 23 October 2003 @ 15:01:
[...]


hmm rustig maar

[Xboty]

ja toch mensen moeten zich niet zo opwinden t is maar een forum en we zijn hier toch om elkaar te helpen

[Verwijderd]

Ok nog een poging dan. Ik ben er toch echt bijna... ik heb bijna iedere foutmelding wel gehad en overleefd!

Input, output moet volgens mij werken... met dank aan books online (en dus aan whoami ) maar nu weer een foutmelding die niet duidelijk te traceren is.

Namelijk nr. 217: Maximum stored procedure, function, trigger, or view nesting level exceeded (limit %d).

Hoe ziet het er nu uit?

code:

CREATE PROCEDURE dbo.sp_Rule1

@row_id int, 
@result INT OUT

as

begin
  SELECT @result = count(*) FROM bla bla etc etc...
end
GO

en de trigger (caller van de stored procedure):

code:

BEGIN
declare @return_waarde int;
declare @result int;
declare @resultfromprocedure int;

SELECT @return_waarde = ServiceID FROM inserted
EXEC  sp_BeginOfProcessObject_rule1 @return_waarde, @result = @resultfromprocedure output;

if @resultfromprocedure = 1 BEGIN
    update TService set Status = 'melding' Where TService.ServiceID = @return_waarde
    END

END

[whoami]

Blijkbaar triggert die SP die je vanuit die trigger uitvoert opnieuw die trigger, die op zijn beurt opnieuw die procedure uitvoert, etc...

Blijkbaar wordt jouw trigger ook uitgevoerd als je een update doet op die tabel, is dat wel nodig?

[Verwijderd]

Right on!!! Je hebt helemaal gelijk. Omdat er een veldje uit de tabel wordt ingevuld (update actie), wordt de trigger opnieuw uitgevoerd en zit ie in een loop.

Ik moet het veldje status dus 'excluden' oftewel buiten de scope van de trigger plaatsen.

trigger afvuren voor zowel insert als update is idd noodzakelijk.

[ Voor 15% gewijzigd door Verwijderd op 23-10-2003 16:29 ]

[whoami]

Moet die trigger wel bij elke UPDATE actie ook uitgevoerd worden? Is een INSERT trigger niet voldoende?

[Verwijderd]

Nee het moet echt ook na een update.

Daar moet toch een goede oplossing voor zijn? Het is een standaardprobleem, dat heb ik wel gevonden op het internet... maar ik zoek me suf. Niemand die ook een oplossing heeft hiervoor.

Volgens mij klopt het doorgeven van de parameters ook nog steeds niet... wat een ellende!

[whoami]

Uit de Books online:

How to set the nested triggers option (Enterprise Manager)
To set the nested triggers option

Expand a server group.

Right-click a server, and then click Properties.

Click the Server Settings tab.

Under Server behavior, select or clear the Allow triggers to be fired which fire other triggers (nested triggers) check box.

Dit heeft me dus 2 seconden gekost om dat te zoeken. Misschien moet je dat zelf ook eens doen.

[Annie]

Is het uberhaupt wel noodzakelijk dat er meerdere triggers afvuren? Ik zou eerst eens in kaart brengen wat er op welk moment moet gebeuren en de triggers en sp's op basis daarvan inrichten. En houdt daarbij in je achterhoofd dat een update uit een delete en een insert bestaat.
Je kan in de trigger condities opnemen wanneer deze een update moet uitvoeren.

Het lijkt er nu wel heel erg op dat de nested triggers een ongewenst bijproduct is van een niet goed doordachte oplossing. Als ik mis zit dan mijn excuses, ik heb het topic niet helemaal aandachtig doorgenomen.

En als je dan toch aan het kijken bent naar je oplossing kijk dan ook eens bij "instead of" triggers (sql2000) in de books. Daar kan je ook een heleboel leuke dingen mee doen en misschien komt het nog van pas.

[ Voor 15% gewijzigd door Annie op 23-10-2003 23:11 ]

[Verwijderd]

Hi Whoami,

Als je geen zin hebt om op mijn berichten te reageren, dan moet je dat ook vooral niet doen. Ik doe wat ik kan om mijn probleem op te lossen. Annie maakt een verstandige opmerking, dat het misschien een onverstandige oplossing is. Als ik nu, net zoals jij, binnen 2 seconden het nesting trigger probleem induik, krijg ik daar misschien ook mee te maken.

De books online heb ik nu ook ontdekt en ik zal het zeker gebruiken. Vanochtend heb ik het 'SQL Server 2000 stored procedure & xml programming' boek gekocht en ga mij eens goed inlezen in het onderwerp en dan ga ik er vast wel uitkomen.

Ik blijf er overigens bij dat hetgene wat ik wil doen met de stored procedures ongetwijfeld een zeer veelvuldig voorkomend mechanisme is. Is er dan niemand die hier uit de oude doos zijn of haar standaard scriptjes voor kan posten???

Uit de Books online:

[...]


Dit heeft me dus 2 seconden gekost om dat te zoeken. Misschien moet je dat zelf ook eens doen.

[whoami]

[nohtml]

Verwijderd schreef op 24 October 2003 @ 13:41:

Als je geen zin hebt om op mijn berichten te reageren, dan moet je dat ook vooral niet doen.

Als ik geen zin heb om op berichten te reageren, dan doe ik dat ook niet.
Wat me wel een beetje ergert, is dat jij hier je probleem post zonder dat je blijkbaar zelf ook ff de moeite doet om een oplossing te zoeken in die Books Online, ook als je al een hint in de goeie richting gekregen hebt.
Daarnaast had ik je al behoorlijk verder geholpen, en je voldoende hints gegeven. Blijkbaar nam je die hints ook wel in beschouwing, maar dan verwachten we hier ook wel dat je zelf ff verder gaat gaan kijken, ipv kant en klare oplossingen te verwachten.

Ik blijf er overigens bij dat hetgene wat ik wil doen met de stored procedures ongetwijfeld een zeer veelvuldig voorkomend mechanisme is. Is er dan niemand die hier uit de oude doos zijn of haar standaard scriptjes voor kan posten???

scriptrequests zijn hier niet toegestaan. Zomaar scriptjes posten , dat doen we dus niet.
Misschien moet je maar eens naar die INSTEAD OF triggers kijken, want ik geloof dat een INSTEAD OF trigger geen 'nesting' doet.

[Verwijderd]

Zoals ik eerder al gezegd heb, ik was gisteren de gehele dag met dit onderwerp bezig (en met het schrijven van de stored procedures die ik vanuit triggers wil aanroepen al eerder 2,5 dag). Het was meer mijn onbekendheid met het onderwerp dat de vooruitgang niet zo dramatisch groot was. Dus reken me a.u.b. niet te snel af op het feit dat ik geen moeite doe om zelf te researchen. Het tegendeel is namelijk het geval.

Alleen jij weet ook dat het problematische soms in de details zit waarom een geheel script niet werkt. Ik zie dan ook geen reden waarom scripts requests niet zijn toegestaan. Als een scriptvoorbeeld verhelderend werkt en de achterliggende principes waarover wordt gesproken ondersteunt, zou ik het zelf absoluut toestaan.

Het lijkt me dat het GoT forum door script voorbeelden alleen maar waardevoller wordt. Mensen komen hier om een oplossing te zoeken voor hun probleem. Als een compleet script deze oplossing biedt.. so be it. Geen enkel script is volledig over te nemen, je zult sowieso moeten aanpassen naar je eigen specifieke situatie. Het argument dat mensen 'de community' 'misbruiken' voor het zoeken naar een snelle, eenvoudige en kant-en-klare oplossing is iets wat mij zeer logisch lijkt (!). Als je niet wilt dat mensen dit doen, moeten mensen hun hulp niet aanbieden. Als forumbeheerder kun je dit gedrag niet tegengaan.

Wat zijn de redenen waarom jullie dit niet toestaan?

[Annie]

offtopic:
Discussies over het beleid van het forum kan je beter voeren in het onderdeel van het forum wat daarvoor bedoeld is. Dat houdt deze draad tenminste een beetje ontopic.

Overigens moet ik zeggen dat ik een beetje verbaasd ben op de manier waarop je reageert op de hulp van whoami. Waarschijnlijk niet zo hard bedoelt, maar ze komen niet erg dankbaar over.

[Verwijderd]

<span style="color:blue">Dit is geen bericht van mij.</span>

[ Voor 143% gewijzigd door Verwijderd op 26-10-2003 09:48 ]

[curry684]

Verwijderd schreef op 24 October 2003 @ 14:24:
[...knip blabla scriptrequest...]
Wat zijn de redenen waarom jullie dit niet toestaan?

Omdat dit een forum is om te discussieren over programmeren en geen afhaalbalie voor kant en klare code. Punt.

www.codebase.com, www.hotscripts.com, www.dynamicdrive.com, www.codeguru.com zijn enkele sites die me te binnen schieten als online repositories van kant en klare code. Als wij hier met onze userbase script requests zouden toestaan zouden we letterlijk enkele tientallen vragen per dag krijgen om hele routines. En ja, als forumbeheerder kunnen wij perfect script requests tegengaan: we zetten ze linea recta op slot of in de TrashCan als ze echt te bot zijn. Werkt al 5 jaar perfect hoor

Tot slot gaat dit nu volledig offtopic, en zoals Annie reeds aangeeft horen discussies aangaande het beleid in Lieve Adjes thuis. Daar kun je tevens middels de search al tientallen eerdere discussies over het beleid van P&W terugvinden, echter voordat je daar in duikt kun je beter even [rml][ P&W] Het Grote Klanttevredenheidsonderzoek[/rml] doorlezen, 95% van de bezoekers bevalt het op dit moment extreem goed