[VBA/Access]Waarde van een variabele form input opvragen

[456]

Ik heb een formulier waarop 18 pull down menu's staan, met de namen:
invoer_rijtuig1
invoer_rijtuig2
...
invoer_rijtuig18

Nu kan ik middels de normale opvraagmanier:

code:

rijtuig1 = Form_invoer_treingegevens.invoer_rijtuig1
rijtuig2 = Form_invoer_treingegevens.invoer_rijtuig2
..
rijtuig3 = Form_invoer_treingegevens.invoer_rijtuig18

alles wel declareren, maar erg netjes vind ik dit niet. Mooier is om dit in een loop te doen. Dus heb ik het volgende bedacht:

code:

Sub test()
Dim evaluate As String

Count = 1

While Count <= 18

evaluate = "Form_invoer_treingegevens.invoer_rijtuig" & Count
Value = Eval(evaluate)

Count = Count + 1
Wend
End Sub

(NB! het gaat mij er even NIET om dat alle 18 ingevoerde waarden in 18 verschillende strings worden geplaatst, het gaat me enkel om het feit een variabele uit de form in 1 string te zetten)

Dit werkt dus niet. Het blijft steevast zeggen dat Form_invoer_treingegevens niet te vinden is in de welke form dan ook. Dit terwijl ik een Integer zo wil opvragen (bijv: Form_invoer_treingegevens.invoer_integer (onder de aanname dat dat ook in de form staat!)) dan werkt het wel!
Maar omdat een combo box een string stuurt, slaat die eval regel dus vast.

Iemand een idee hoe ik dit makkelijk kan oplossen?
bvd!

[eghie]

Ik vind die while loop eig een beetje fout, want op die manier die jij gebruikt kun je beter een for loop gebruiken, want die zijn daarvoor ontworden.

[Lustucru]

Ik mis in die evaluatestring de verwijzing naar de formulierencollectie. Access kan niet weten dat jij met die zwik tekst wilt verwijzen naar een geopend formulier. 'forms!blaat zou kunnen werken, maar eval is hier misplaatst. Waarom niet:

code:

 strControlName="invoer_rijtuig" & cstr(Count)
 value=me.controls(strControlName)

'me' als de code in het formulier zelf staat, anders uiteraard forms![frmnaam]

[456]

Om jullie allebei tegemoet te komen:

code:

Sub test()
Dim evaluate As String

i = 1

For i = 1 To 18
 
evaluate = "invoer" & CStr(i)
Value = Form_trein.Controls(evaluate)

Next i

End Sub

(nb: form naam iets aangepast vanwege test)

both of you!

[ Voor 6% gewijzigd door 456 op 28-07-2004 13:35 ]

[farlane]

Mag je geen control array maken in Access?

[Lustucru]

farlane schreef op 28 juli 2004 @ 13:34:
Mag je geen control array maken in Access?

Afaik niet nee.

[farlane]

Dan zou je em nog in je control collectie kunnen indexeren

Visual Basic:

Me.Controls( "Naampje" ).Text

[Lustucru]

farlane schreef op 28 juli 2004 @ 14:06:
Dan zou je em nog in je control collectie kunnen indexeren

Visual Basic:

Me.Controls( "Naampje" ).Text

ja, en wat voegt dat toe aan wat er al staat:

code:

Me.Controls(strControlName)

[456]

Niesje schreef op 28 juli 2004 @ 14:21:
[...]

ja, en wat voegt dat toe aan wat er al staat:

code:

Me.Controls(strControlName)

In weze is het natuurlijk hetzelfde idd. Jouw methode heeft vooralsnog mijn voorkeur, het is nl. beter te zien welke value strControlName aanneemt, waardoor een fout eerder te vinden is.
Wellicht als ik eea dalijk ga implementeren dat ik die stap oversla, en farelane's opm me ter harte neem. Scheelt weer een lijn tekst.

Overigens hoef ik niet '.text' erachter te zetten. Hij neemt zo al de waarde over.

[farlane]

Niesje schreef op 28 juli 2004 @ 14:21:
[...]

ja, en wat voegt dat toe aan wat er al staat:

code:

Me.Controls(strControlName)

Nix, ik has de code niet echt goed bekeken.

Overigens hoef ik niet '.text' erachter te zetten. Hij neemt zo al de waarde over.

Default properties zijn evil. Voor de duidelijkheid zou het verplicht moeten zijn om alle properties voluit te typen, maar daar denkt MS in zijn oneindige wijsheid anders over.

Overigens bestaan ze volgens mij in de .Net reeks al niet meer, dus als je en keer zou willen overstappen is het een goed idee om er aan te wennen.

Btw, Als je echt zoveel menus hebt, is het misschien de moeite waard om een iets andere ui constructie te bedenken.

[ Voor 9% gewijzigd door farlane op 28-07-2004 17:15 ]

[456]

farlane schreef op 28 juli 2004 @ 17:12:
[...]


Nix, ik has de code niet echt goed bekeken.


[...]


Default properties zijn evil. Voor de duidelijkheid zou het verplicht moeten zijn om alle properties voluit te typen, maar daar denkt MS in zijn oneindige wijsheid anders over.

Hmm. daar zit wat in. Het zou ook beter sommige acties verklaren, ook voor je zelf als je een fout ergens hebt zitten.

Btw, Als je echt zoveel menus hebt, is het misschien de moeite waard om een iets andere ui constructie te bedenken.

Negative... Er moet een zgn. treinsamenstelling (dus alle wagons achter de locomotief) ingevoerd worden, wat kan oplopen tot 18 wagons (in mijn geval). De type wagons staan ook in de dbase, en worden weergegeven in de pop down list.
Ik zie zo snel even niet hoe dat anders te doen.

[eghie]

farlane schreef op 28 juli 2004 @ 17:12:
[...]


Nix, ik has de code niet echt goed bekeken.


[...]


Default properties zijn evil. Voor de duidelijkheid zou het verplicht moeten zijn om alle properties voluit te typen, maar daar denkt MS in zijn oneindige wijsheid anders over.

Overigens bestaan ze volgens mij in de .Net reeks al niet meer, dus als je en keer zou willen overstappen is het een goed idee om er aan te wennen.

Btw, Als je echt zoveel menus hebt, is het misschien de moeite waard om een iets andere ui constructie te bedenken.

In de .Net platform bestaan ze trouwens ook nog en ik gebruik ze ook gewoon altijd. Je hebt idd gelijk dat Me.Controls("textboxje").text beter is dan Me.Controls("textboxje"), want voor sommige controls wil hij nog wel eens een heel andere waarde teruggeven.

Ik las dus dat er in acces dus geen mogelijkheid is voor een control array. Dat zou wel een mooie mogelijkheid geweest zijn, want dan kan het veel makkelijker en sneller.

[Max|Burn]

Begrijp ik nu goed dat je een tabel locomotief heb met daarin 18 velden aan wagons.. ( ? )
ik hoop van niet

(edit: ik snap dat t slightly offtopic is)

[ Voor 24% gewijzigd door Max|Burn op 28-07-2004 22:13 ]

[Lustucru]

456 schreef op 28 juli 2004 @ 19:38:
[...]
Negative... Er moet een zgn. treinsamenstelling (dus alle wagons achter de locomotief) ingevoerd worden, wat kan oplopen tot 18 wagons (in mijn geval). De type wagons staan ook in de dbase, en worden weergegeven in de pop down list.
Ik zie zo snel even niet hoe dat anders te doen.

MaxBurn schreef op 28 juli 2004 @ 22:04:
Begrijp ik nu goed dat je een tabel locomotief heb met daarin 18 velden aan wagons.. ( ? )
ik hoop van niet

(edit: ik snap dat t slightly offtopic is)

Ben bang dat je gelijk hebt. Dat zou er idd voor pleiten om het even om te gooien:
tabel trein en een tabel treinsamenstelling met ordinal en wagon en als UI een hoofd/sub formulier.

[Max|Burn]

Ik dacht aan:

Tabel Locomotief: LocID
Tabel Loc_Wagon: WagonID, LocID (extra key is niet nodig, deze combo op zich is uniek)
Tabel Wagon: WagonID, TypeID
Tabel Wagon_Type: TypeID, Omschrijving

Bovenstaande is iig een nette structuur, ik weet niet of de TS het zo heeft maar een dergelijke structuur is wel aan te raden

Een loc kan 0 of meerdere wagons hebben, 1 wagon hoort optioneel bij 1 loc(neem aan dat hij ook ergens in een rangeerterrein/weggezet kan staan ofzo hehe), een wagon is altijd van 1 type, een type kan voorkomen bij meerdere wagons, etc

[ Voor 68% gewijzigd door Max|Burn op 28-07-2004 23:35 ]

[456]

Ok, vanwege de goede reacties, even wat moeite van mijn kant mijn wat grotere projectje uit te kramen.

De bedoeling is om een klein reserverings systeempje te maken. Afhankelijk van de te gebruiken wagons, op een bepaalde datum, met een bepaalde bestemming kunnen er dus plaatsen worden geboekt/geblockt voor de passagiers.
De structuur is dan als volgt (wellicht enig trein jargon):

Alereerst de gehele dbase (daarna uitleg waar ze voor staan):

code:

Tabel rijtuiggegevens: rijtuig_type (PK), aantal_slaapplaatsen, aantal_ligplaatsen, aantal_zitplaatsen
Tabel treingegevens: trein_id (PK), datum, treinnummer, samenstelling, rijtuig_nrs
Tabel dossiergegevens: dossier_id (PK), aantal, trein_id
Tabel reserveringsgegevens: trein_id, dossier_id, rijtuig_nr, stoel_nr

(laatste 2 tabellen moet ik echt nog goed over nadenken hoe ze eruit moeten gaan zien)
PK = Primary Key

Uitleg:
De tabel rijtuiggegevens is bedoeld om de eigenschappen van een in te zetten wagon (=rijtuig) op te slaan. Zoals je kan zien kan het slaapplaatsen bezitten OF ligplaatsen OF zitplaatsen. Ook kan het geen plaatsen hebben (maar meot het wel in de database om later een ComboBox te vullen), zoals een bar rijtuig bijvoorbeeld.

De tabel treingegevens is een cruciale. Hier wordt een te rijden trein gedefinieerd:
De combinatie datum en treinnummer zijn uniek, ik heb er voor gekozen toch een trein_id te laten genereren (auto_nummering) om zo minder informatie op te hoeven slaan in andere tabellen, en te communiceren met het trein_id.
Een treinnummer is eigenlijk een soort vluchtnummer bij vliegtuigen. Het heeft dus eigenlijk ook in zich wat de bestemming is.
Bij invoer van treingegevens moet dus een datum EN een treinnummer worden ingevoerd (er vindt controle plaats in vba of dit uniek is). Tevens moeten er de wagons uit de tabel rijtuiggegevens worden toegevoegd
(ik heb 18 ComboBoxjes gemaakt, wat dus voor 18 wagons staat. Maximaal kan maar 15 wagons vervoerd worden, dus ik heb een kleine marge).
Omdat een type wagon een nummer mee krijgt in de spoorwereld, moet achter elke ingevoerde wagon een zgn treinnummer worden gegeven, dit komt later ook van pas om reserveringen in een wagon in te boeken.

De tabel dossiergegevens moet dalijk alle informatie van de reservering van de klant op gaan nemen. Zoals gezegd is ie nog niet klaar. Maar belangrijk is bv: heenwegdatum, terugwegdatum, bestemming etc. Daar er bij invoer op een formulier al ingevoerd moet worden:'bestemming en datum' heeft de opslag van datum en bestemming (wat in feite dus die bestemming is) kan met die informatie dus het trein_id worden opgespoord. Het lijkt mij dan voldoende dit op te slaan in de dossiergegevens.

Tot slot de reserveringstabel. Hier komen alle gemaakte reserveringen in, om zo tot een 'optel'som te komen of een bepaalde trein al vol zit.
Dit heeft lastige bewerkingen tot gevolg, maar met de info die er opgeslagen is moet het wel kunnen.
Want ik maak nu voor elke keer dat er een bewerking moet worden gedaan, of informatie over een trein moet worden opgehaald een MultiArray aan, met daarin alle gegevens van een trein (beschikbaarheid, gedane boekingen etc). Dit is allemaal uit alle tabellen te halen.

Enfin, het is een hele lap tekst. Zij die het lezen willen, leze het. Zij die het teveel vinden zappen maar weg Ik sta open voor tips/kritiek (mits opbouwend).

Iig nog bedankt voor alle reacties!

[Bolhuis]

456 schreef op 29 juli 2004 @ 12:26:
Ok, vanwege de goede reacties, even wat moeite van mijn kant mijn wat grotere projectje uit te kramen.

De bedoeling is om een klein reserverings systeempje te maken. Afhankelijk van de te gebruiken wagons, op een bepaalde datum, met een bepaalde bestemming kunnen er dus plaatsen worden geboekt/geblockt voor de passagiers.
De structuur is dan als volgt (wellicht enig trein jargon):

Alereerst de gehele dbase (daarna uitleg waar ze voor staan):

code:

Tabel rijtuiggegevens: rijtuig_type (PK), aantal_slaapplaatsen, aantal_ligplaatsen, aantal_zitplaatsen
Tabel treingegevens: trein_id (PK), datum, treinnummer, samenstelling, rijtuig_nrs
Tabel dossiergegevens: dossier_id (PK), aantal, trein_id
Tabel reserveringsgegevens: trein_id, dossier_id, rijtuig_nr, stoel_nr

(laatste 2 tabellen moet ik echt nog goed over nadenken hoe ze eruit moeten gaan zien)
PK = Primary Key

Uitleg:
De tabel rijtuiggegevens is bedoeld om de eigenschappen van een in te zetten wagon (=rijtuig) op te slaan. Zoals je kan zien kan het slaapplaatsen bezitten OF ligplaatsen OF zitplaatsen. Ook kan het geen plaatsen hebben (maar meot het wel in de database om later een ComboBox te vullen), zoals een bar rijtuig bijvoorbeeld.

De tabel treingegevens is een cruciale. Hier wordt een te rijden trein gedefinieerd:
De combinatie datum en treinnummer zijn uniek, ik heb er voor gekozen toch een trein_id te laten genereren (auto_nummering) om zo minder informatie op te hoeven slaan in andere tabellen, en te communiceren met het trein_id.
Een treinnummer is eigenlijk een soort vluchtnummer bij vliegtuigen. Het heeft dus eigenlijk ook in zich wat de bestemming is.
Bij invoer van treingegevens moet dus een datum EN een treinnummer worden ingevoerd (er vindt controle plaats in vba of dit uniek is). Tevens moeten er de wagons uit de tabel rijtuiggegevens worden toegevoegd
(ik heb 18 ComboBoxjes gemaakt, wat dus voor 18 wagons staat. Maximaal kan maar 15 wagons vervoerd worden, dus ik heb een kleine marge).
Omdat een type wagon een nummer mee krijgt in de spoorwereld, moet achter elke ingevoerde wagon een zgn treinnummer worden gegeven, dit komt later ook van pas om reserveringen in een wagon in te boeken.

De tabel dossiergegevens moet dalijk alle informatie van de reservering van de klant op gaan nemen. Zoals gezegd is ie nog niet klaar. Maar belangrijk is bv: heenwegdatum, terugwegdatum, bestemming etc. Daar er bij invoer op een formulier al ingevoerd moet worden:'bestemming en datum' heeft de opslag van datum en bestemming (wat in feite dus die bestemming is) kan met die informatie dus het trein_id worden opgespoord. Het lijkt mij dan voldoende dit op te slaan in de dossiergegevens.

Tot slot de reserveringstabel. Hier komen alle gemaakte reserveringen in, om zo tot een 'optel'som te komen of een bepaalde trein al vol zit.
Dit heeft lastige bewerkingen tot gevolg, maar met de info die er opgeslagen is moet het wel kunnen.
Want ik maak nu voor elke keer dat er een bewerking moet worden gedaan, of informatie over een trein moet worden opgehaald een MultiArray aan, met daarin alle gegevens van een trein (beschikbaarheid, gedane boekingen etc). Dit is allemaal uit alle tabellen te halen.

Enfin, het is een hele lap tekst. Zij die het lezen willen, leze het. Zij die het teveel vinden zappen maar weg Ik sta open voor tips/kritiek (mits opbouwend).

Iig nog bedankt voor alle reacties!

Misschien roep ik hier nu als nieuweling iets doms maar toch!
Wat ik hierin mis is de koppeling tussen de tabellen rijtuiggegevens en treingegevens. Volgens mij moet je in de tabel rijtuiggegevens een veld rijtuig_nr opnemen welke dan moet aansluiten op het veld rijtuig_nrs in de tabel treingegevens.

Ook is het mij nog onduidelijk waar je de stoelgegevens per trein vastlegt.

[456]

Bolhuis schreef op 29 juli 2004 @ 14:31:
[...]


Misschien roep ik hier nu als nieuweling iets doms maar toch!
Wat ik hierin mis is de koppeling tussen de tabellen rijtuiggegevens en treingegevens. Volgens mij moet je in de tabel rijtuiggegevens een veld rijtuig_nr opnemen welke dan moet aansluiten op het veld rijtuig_nrs in de tabel treingegevens.

Ook is het mij nog onduidelijk waar je de stoelgegevens per trein vastlegt.

1e punt:
Ik zie niet in waarom die koppeling er tussen die 2 tabellen moet zijn. Immers, de tabel rijtuiggegevens is enkel en alleen maar opslag voor de eigenschappen van de rijtuigen. Die dient er niet voor om daarin op te slaan welk rijtuig wanneer in welke trein zit. Enkel en alleen maar wat voor type het is, en de capaciteit voor verdere bewerking.

2e punt sluit daar op aan: Jij snapt wel degelijk het probleem als nieuweling! Immers, die stoel (of eigenlijk coupe configuratie) die zit er nog niet in. Dit is wel iets om dalijk in de tabel rijtuiggegevens op te slaan mijn inziens.

[Bolhuis]

456 schreef op 29 juli 2004 @ 14:36:
[...]

1e punt:
Ik zie niet in waarom die koppeling er tussen die 2 tabellen moet zijn. Immers, de tabel rijtuiggegevens is enkel en alleen maar opslag voor de eigenschappen van de rijtuigen. Die dient er niet voor om daarin op te slaan welk rijtuig wanneer in welke trein zit. Enkel en alleen maar wat voor type het is, en de capaciteit voor verdere bewerking.

2e punt sluit daar op aan: Jij snapt wel degelijk het probleem als nieuweling! Immers, die stoel (of eigenlijk coupe configuratie) die zit er nog niet in. Dit is wel iets om dalijk in de tabel rijtuiggegevens op te slaan mijn inziens.

Maar dan zul je mijn punt 1 juist wel moeten opzetten, anders weet je nooit welke eigenschappen de rijtuigen in een trein hebben en kun je dus ook niet matchen.

[456]

Nee, want de eigenschappen van een wagon zijn toch niet afhankelijk van de gehele trein?
Wellicht snap ik (nog) niet zo goed wat je bedoelt hoor, dat kan ook
Maar de eigenschappen van de rijtuigen zijn enkel fysiek:
Aantal bedden/stoelen per coupe's, aantal coupe's, nummering coupe's/zit/slaapplaatsen.

De eigenschappen van de trein zijn dan (Afgezien van datum ed) afhankelijk van de eigenschappen van de rijtuigen: bv 3x type rijtuig 1e klas = 3x 40 zitplaatsen = 120 zitplaatsen 1e klas totaal

contact me eventueel op MSN/ICQ

[Max|Burn]

uhm je hou rijtuig_nr's bij in trein maar verder is dat nergens aan gekoppeld?
een rijtuig_nr is een daadwerkelijk bestaand rijtuig zoals ik het begrijp..die wil je dan ook bijhouden toch?

Op dit moment kan jij 1 rijtuig aan 1000000 treinen koppelen als je wilt..dat lijkt me niet echt mogelijk (edit ok je heb er een datum aan maar toch..)

de structuur die ik aangaf voor het treindeel lijkt me nog steeds niet verkeerd..

code:

Tabel treingegevens: trein_id (PK), datum, treinnummer, samenstelling, rijtuig1, rijtuig2, 
rijtuig3...rijtuig18

vraag1: begrijp ik nou goed dat je dus zo de data opsla?..
dat is eng.. krijg ik kippevel van.

vraag2: treingegevens is een soort vlucht..maar treinnummer en rijtuignr staan dus nergens aan gekoppeld?

vraag3: hoe weet je van welktype een rijtuignr is als er geen koppeling is tussen rijtuignrs en types?

[ Voor 47% gewijzigd door Max|Burn op 29-07-2004 16:01 ]

[456]

MaxBurn schreef op 29 juli 2004 @ 15:49:

vraag1: begrijp ik nou goed dat je dus zo de data opsla?..
dat is eng.. krijg ik kippevel van.

vraag2: treingegevens is een soort vlucht..maar treinnummer en rijtuignr staan dus nergens aan gekoppeld?

vraag3: hoe weet je van welktype een rijtuignr is als er geen koppeling is tussen rijtuignrs en types?

antwoord 1: Klopt (dwz ik heb het niet gedaan zoals jij zegt), dat had ik wellicht even mogen uitleggen in eerder genoemde post.

De samenstelling wordt evenals de rijtuignummers als 1 string opgeslagen:
Zo kan samenstelling er zo uit komen te zien: ab, ab, bar, i5, bcvm, bcm
(dit zijn de rijtuigtypes)
Rijtuignummers komt er dan zo uit te zien: 931, 930, bar, 889, 888, 887
Ofwel:

code:

INSERT INTO bla (samenstelling, rijtuignummers) VALUES 
('ab, ab, bar, i5, bcvm, bcm', '931, 930, bar, 889, 888, 887')

(vereenvoudigde query)

Van belang is dat dit ook zo wordt ingevoerd (wordt het op gecheckt!) want zo kan je dus gemakkelijk samenstelling en rijtuignummers in een array knallen:

code:

ab 931
ab 930
bar bar
i5 889 
... 
etc

En zo kan ik die array nog meer vullen (bv met max hoeveelheid plaats, reeds gereserveerde plaatsen etc.)

Ik denk toch dat het komt vanwege het feit dat ik tekort schiet in het uitleggen, en niet zozeer in het systeem. Ik zal de laatste zijn die zegt dat dit ideaal is, maar gezien de verschillende variabelen lijkt het moeilijker dan het is.

Antwoord 2: Dat is het dus wel: in de trein_gegevens tabel

Antwoord 3: Die vraag is eigenlijk al een beetje beantwoord in antwoord 1: Een rijtuignummer zegt niets over een type en dus ook niet over de hoeveelheid beschikbare plaatsen. Een type zegt dat dus wel (en die kan je vinden in de samenstelling.

Om eea inzichtelijk te maken het volgende andere wat practischere voorbeeld:
We hebben reeds eerder gezegd dat Treinnummer overeenkomt met een vluchtnummer:
Een reserveringssysteem van een vliegtuigmaatschappij kan er dan als volgt uit zien:

code:

Vluchtnummer(PK)  Type_vliegtuig

in conreto: KL456 Boeing737

Nu moet je dus in de tabel vliegtuiggegevens gaan kijken wat de eigenschappen zijn van een boeing 737, laten we zeggen 180 passagiers (in een bepaalde configuratie). Er is nog steeds niet bekend welk vliegtuig gaat vliegen.
Later blijkt dan de PH-BUZ gevlogen te hebben, wat het vliegtuig een echte naam geeft (met dus de eigenschappen van de boeing 737).

Nu zit het bij mij iets anders (een echt rijtuig kan de ene week 930 heten, en de andere week 931 bv) maar het is ongeveer de zelfde gedachtenslag.

edit: In de database sla ik niet op hoeveel rijtuigen ik heb, of het logistiek mogelijk is. Dit is enkel om te reserveren, een plaats toe te wijzen aan een ingeboekte passagier. Dus je hebt gelijk, een rijtuigNUMMER kan 10000 voorkomen (echter maar 1x per datum/treinnummer)

[ Voor 14% gewijzigd door 456 op 29-07-2004 16:27 ]

[Max|Burn]

rijtuig_type linkt nergens mee maar je haal het type uit samenstelling..ik vind het allemaal erg inconsistent en redundant opgezet

met een koppeling bedoelen we de link tussen 2 tabellen..(bv een koppeltabel of simpelweg via een key) Dus het feit dat je treinnummer en rijtuignrs(als string..brr) in 1 tabel staan betekent niet dat er echt een koppeling is.

naja ik weet niet hoe ik het uit wil leggen maar erg veel klopt er niet van..
als dit zo werkt voor je zal je mij niet meer horen

ps:

Als ik
op 29-7-2004 treinnummer 3 heb met rijtuigen B1,B2,B3 (als string)
en
op 29-7-2004 treinnummer 4 heb met rijtuigen B3,B1,B2 (als string)

hoe vang je dit nu af?...lijkt me niet dat je je rijtuigen door midden snij.

Persoonlijk zou ik zelf de hele database opnieuw gebouwd hebben en de structuur genormaliseerd hebben..

[ Voor 144% gewijzigd door Max|Burn op 29-07-2004 17:03 ]