Verschil in tabel in frontend en backend

[EdHa]

Ik heb een behoorlijk raar probleem. Ik heb een gesplitste database met een frontend en een backend. In de backend staan (uiteraard) de tabellen, in de frontend de queries en de formulieren en de gekoppelde tabellen (met pijltjes). Ik heb een bepaalde tabel, laten we hem maar even 'klanten' noemen, die fouten gaf verwijderd en opnieuw gekoppeld. So far so good.

Als ik in de backend de tabel bekijk op velden die hun waarde uit een gekoppelde tabel halen (plaatsnamen bijv) zie ik keurig de plaatsnaam staan. Op advies van Octafish heb ik netjes alle opzoekdingen uit de backend gehaald en die velden gekoppeld zoals in een eerder draadje beschreven. Het ID-veld van de plaats gekoppeld met een numeriek veld in de tabel Klanten voor de plaats.

Als ik nu in de frontend dezelfde tabel bekijk zie ik geen plaatsnamen maar de nummers staan van waar de gekoppelde plaatsnamen in de tabel plaatsen voorkomen. Hoe kan dit? Hoe kan het dat ik in de originele tabel de namen zie en in de gekoppelde tabel in de frontend de nummers? Kan dat te maken hebben met het eventueel gelegd hebben van een (nieuwe) relatie in de frontend in mijn zoektocht naar oplossingen voor andere problemen? Ik weet niet of ik dat gedaan heb, maar sluit het niet helemaal uit. Het kan zijn dat ik in een query die niet werkte een relatie tussen tabellen heb aangebracht die niet spontaan verscheen (zou moeten toch als in de oorspronkelijke backend de juiste relaties zijn gelegd?). In de query zie je nl soms niet de plaats (maar het nummer) als je die uit de tabel Klanten wilt halen en haal ik die dus uit de tabel Plaatsen waarbij de relatie niet (altijd) vanzelf verschijnt.

Ik heb soms het idee dat ik gek word. Hele tijden gaat het goed en kom ik steeds verder en dan ineens loop ik weer tegen zoiets onverklaarbaars aan en zakt de moed me weer in de schoenen.

 

[OctaFish]

Als ik in de backend de tabel bekijk op velden die hun waarde uit een gekoppelde tabel halen (plaatsnamen bijv) zie ik keurig de plaatsnaam staan.

Je hebt mijn opmerkingen vermoed ik niet helemaal juist begrepen. Ik denk dat je wél de koppelingen tussen de tabellen hebt gelegd, maar in de tabel zelf nog steeds opzoeklijsten gebruikt. Welnu: als er één doodzonde is in een tabel, dan is het wel opzoektabellen gebruiken in een tabel . Althans: in mijn (bescheiden) ogen. Mijn belangrijkste regel, en die herhaal ik dan ook in elke vraag waarin de steller opzoeklijsten gebruikt is heel simpel:
Gebruik in tabellen géén opzoeklijsten op basis van een tabel. Simpele regel, niet? Neemt niet weg dat ik best wel eens een opzoeklijst gebruik, maar alleen op basis van een lijst met waarden. Bijvoorbeeld in het geval van het veld [Geslacht]. Daar kan ik met de beste wil van de wereld niet meer dan 3 waarden voor verzinnen: Man, Vrouw, Onbekend. Daar maak ik dus géén tabel voor.

Waarom die hoofdregel? Om dit soort ellende dat jij nu beschrijft te voorkomen! . Maar dat niet alleen: ik vind dat je te allen tijde in een tabel moet kunnen zien wat er letterlijk staat. In je tabel Klanten stáát in het veld Plaatsnaam niet "Rotterdam', maar de waarde 1. Of welk ID nummer je daar ook voor gebruikt. (al zou het logisch zijn om Rotterdam standaard op 1 te hebben ). Dat je in de Frontend de feitenlijke waarde wél ziet, is dus prachtig, en daar moet je niets aan doen! Wanneer (en waar) gebruik je dan wél keuzelijsten (met invoervak)? Simpel: alleen op formulieren. Dáár wil je juist niet op nummers moeten zoeken, maar op karakters. En dáár zoek je dus wél op "Rotterdam". Dat op de achtergrond in de tabel het getal 1 wordt opgeslagen, is voor de gebruiker ook helemaal niet interessant; die wil gewoon zíen wat hij kiest, en verder niks. Maar gebruikers hebben in mijn ogen ook helemaal niets te zoeken in tabellen of queries. Die bedien je nou juist met je formulieren en rapporten.

Blijft nog de vraag hoe je de plaatsnaam dan in de rapporten etc. krijgt. Ook dat is simpel: zodra je de letterlijke adressen nodig hebt, maak je een query waarin je de tabel Klanten neerzet én de tabel Plaatsnamen. Vervolgens haal je de adresgegevens op uit Klanten, en Plaatsnaam uit Plaatsnamen. Ze zijn gekoppeld op PlaatsID, dus dat komt dan helemaal goed.

Maar onthoud: een tabel is een gegevensbak, niets meer en niets minder. Daarin moet je altijd kunnen zien wat er is opgeslagen. Als je dat zo consequent doet, is je database altijd (op dat gebied) genormaliseerd, en kun je hem ook altijd op de juiste manier filteren, exporteren, upgraden en migreren naar een hoger platform, mocht dat ooit nodig zijn.

 

[EdHa]

Ik wil het heel graag begrijpen, en dacht dat ik dat ook deed tot ik dit euvel ontmoette .

Als ik tussen de tabellen Plaatsen en Klanten een relatie met referentiële integriteit wil leggen wordt die geweigerd als het veld Plaats in de tabel klanten niet numeriek is. Immers, dan probeer je een een numeriek veld aan een tekstveld te koppelen en dat werkt dus niet. Dus je MOET Plaats wel numeriek maken, toch? Of bedoel jij dat je in het gedeelte opzoeken dan niets moet invullen? Het KAN geen tekstveld zijn zoals jij steeds aanbeveelt als,ik je goed begrijp.

Stel dat dit de oplossing is (kan het nu even niet proberen) dan doet zich het volgende voor. In een formulier heb ik een niet-afhankelijk veld, waarin ik in de achterliggende query zoek op een combinatie waarin ook plaats voorkomt. Ik wil dan de gegevens uit die selectie op basis van selectie.column(1), (2) enz overnemen omdat ik bij eenmaal gekozen hebben alleen één kolom kan blijven zien. Ik kan echter het veld Plaats op die manier niet vullen, want daar wordt geen tekst maar 1 (of 2 of 3) verwacht. Hoe los ik dat dan op? Ik pieker me suf maar kom er niet uit.

 

[OctaFish]

Een tabel <Plaatsnamen> ziet er bij mij zo uit:
[PlaatsID] - AutoNummering
[Plaatsnaam] - Tekst (50 karakters of zo)
[ProvincieID] - Lange Integer; koppeling met tabel [Provincies]
of: [LandID] - Lange Integer; koppeling met tabel [Landen]

De tabel [Plaatsnamen] heeft bij mij vaak een koppeling met [Straatnamen], die dan weer een koppeling heeft met Postcodes. Op die manier kun je in de klantentabel volstaan met Postcode + Huisnummer. En dat is de meest economische (en foutbestendige) manier om adressen op te slaan.

Sowieso moet je in het veld Plaats in de tabel Klanten dus een numerieke waarde opslaan. Gebruik je als PlaatsID een autonummerveld, dan moet dat veld in Klanten een Lange Integer zijn, anders krijg je ook een foutmelding.
Ga je met een niet-afhankelijk veld zoeken, op Plaatsnaam bijvoorbeeld, dan zou ik dat ook doen op basis van het getal. In de keuzelijst zie je dan de plaatsnamen, zoals je gewend bent, in de onderliggende waarde heb je het getal uitgelezen. Dat doe je met de eigenschap <Afhankelijke kolom>. Dat is doorgaans dus het eerste (onzichtbare) veld in je keuzelijst. Omdat je in de tabel een getal hebt staan, en in de keuzelijst ook, is het filteren dan helemaal OK.

 

[EdHa]

Dan staat het in de tabel dus goed. Het tabblad opzoeken dan maar niet invullen dus? Dat deed ik nl om de plaatsnaam in de tabel te kunnen zien maar ik begrijp dat dat helemaal niet moet. De tabellen krijgen mijn gebruikers niet te zien dus daar hoeft het niet voor,

Maar dan. Je bent niet ingegaan op mijn vraag om vervolgens het resultaat van de uitgelezen plaats (een getal dus) zichtbaar te maken als plaats.column(2) in een veld en die waarde te gebruiken om in de keuzelijst met invoerveld die de plaats aan de tabel toevoegt de waarde op te nemen. Het niet-afhankelijke veld kan immers de tabel niet aanvullen. Ik heb het geprobeerd met een (re)query van het plaatsvind met de gevonden waarde (de tekst) als parameter, maar mijn probleem is dat je alleen een requery kunt doen als je ook een query hebt. En die wordt bij openen van het formulier natuurlijk uitgevoerd om de inhoud van de tabel op dat moment weer te geven. En als je daar de (dan nog lege) waarde van plaats.column(2) in opneemt wordt de waarde direct weer leeg gemaakt. Ik heb ook de indruk dat de gevonden plaats niet goed wordt gesaved.

Misschien maak ik het allemaal te moeilijk maar ik denk dat op zich moet kunnen wat ik wil, toch?

 

[OctaFish]

Ik gaf nog geen reactie op het tweede deel omdat ik dan niet helemaal snapte. En nu nog niet . In beginsel is het dus zo dat je in de keuzelijst de Afhankelijke kolom verbergt, en de zichtbare kolom is dan Plastsnaam. Heb je in die query meer velden staan, (Provincie, Land) dan kun je die laten zien op je formulier door tekstvakken te koppelen aan de formule cboKeuzelijst.Column(#). Maar dan moeten die velden dus in de keuzelijst (query) aanwezig zijn. De tekstvelden zelf zou ik niet gebruiken om mee te filteren.

 

[EdHa]

Sorry, Ik maak het je niet makkelijk. Wat ik bedoel is dit. Even als voorbeeld.
In een formulier kan de gebruiker in een listbox die niet-afhankelijk is kiezen voor laten we zeggen een evenement op een bepaalde datum in een bepaalde plaats. De niet afhankelijke lijst toont de evenementen met naam, plaats en datum. Het Id van het evenement is het vierde (verborgen) gegeven.
Omdat het kan voorkomen dat iemand op de gekozen datum toch een ander evenement moet kunnen kiezen, of hetzelfde soort evenement op een andere datum of in een andere plaats, wil ik bij de klant niet alleen het gekozen evenement opslaan, maar ook apart de datum, de plaats en de naam.
Je voelt hem nu al aankomen: ik kan eenvoudig de verschillende columns van de keuzelijst in een apart veld vermelden zoals jij ook aangeeft, maar als (zoals bij plaats, maar ook bij naam) de gegevens uit een andere tabel komen kan ik geen veld creëren dat de tabel klanten voorziet van een bijgewerkte datum en naam evenement. Of zie ik iets over het hoofd? En dat is nu net wat ik wel zou willen.
Als er geen mogelijkheid voor is moet ik een andere oplossing kiezen, maar deze zou wel heel plezierig zijn, ook al omdat ik anders bij de keuze van het evenement alleen of de datum, of de plaats of de naam kan laten zien en niet alle drie. Of eigenlijk, laten zien kan nog wel, maar opslaan niet, begrijp je?
Nogmaals mijn dank voor je geduld met en inzet voor ons ijverige, maar soms o zo onwetende hobbyisten.

 

[OctaFish]

Omdat het kan voorkomen dat iemand op de gekozen datum toch een ander evenement moet kunnen kiezen, of hetzelfde soort evenement op een andere datum of in een andere plaats, wil ik bij de klant niet alleen het gekozen evenement opslaan, maar ook apart de datum, de plaats en de naam.

En dat is dus het punt dat je me kwijt raakt! Een evenement komt, zo te zien, uit een tabel met evenenementen met een EvenenemtID, een Plaats, een Datum en vast nog wel wat vaste gegevens. En die zitten allemaal in de tabel [Evenementen] neem ik aan. Als een gebruiker een evenement kiest, dan zie je in de keuzelijst de naam van het evenement staan en verder niks. Dat is logisch; een keuzelijst kan maar één waarde laten zien. Met niet-afhankelijke tekstvakken kun je dan aanvullende velden uit je keuzelijst halen met de formule =cboEvenement.Column(1) etc. Tot zover heb ik het hoop ik goed begrepen, want dan doe je het ook correct. Maar dan:

maar als (..) de gegevens uit een andere tabel komen kan ik geen veld creëren dat de tabel klanten voorziet van een bijgewerkte datum en naam evenement. ...
ook al omdat ik anders bij de keuze van het evenement alleen of de datum, of de plaats of de naam kan laten zien en niet alle drie.

Hier snap ik het dus niet meer... Wát je ook doet, als je een evenement opslaat, dan hoort daar één datum, één plaats etc. bij. Dat heb je immers vastgelegd in de tabel [Evenementen]. Het zou onzinnig zijn om in je tabel een EvenementID op te slaan, en een plaats en een datum van een ander evenement! Dat slaat nergens op! Sowieso ontstaat die mogelijkheid als je voor één evenement meerdere velden gaat gebruiken. Dát is nu juist de hele grap en bedoeling van normaliseren: voorkomen dat er onzinnige informatie wordt opgeslagen!

Wat ik me wél kan voorstellen is dat je niet alleen wilt kunnen zoeken op een evenementnaam, maar ook op plaats en ook op datum. Dat is wél makkelijk te doen; gewoon nog twee keuzelijsten erbij maken waarbij je die velden als eerste zichtbare kolom neerzet. Overigens snap ik het nut niet van de niet-afhankelijke keuzelijst, want mij lijkt het nu juist de bedoeling van je formulier om een evenement te kiezen en op te slaan! En hoe kan je een evenementID opslaan als je de keuzelijst niet aan het veld koppelt? Ik heb je db niet gezien, dus ik kan daar verder weinig nog over zeggen, maar zelf zou ik dus die verschillende keuzelijsten maken, en ze allemaal aan EvenementID koppelen. En dan is het heel simpel, want op het moment dat je in één van de 3 keuzelijsten een waarde kiest (dat is dan een naam, een plaats of een datum) dan krijgen alle keuzelijsten hetzelfde EvenementID. En dat is logisch, want ze zitten allemaal aan hetzelfde veld vast. Dus als de één een waarde krijgt, zie je dat gelijk terug in de andere keuzelijsten.

Ik gebruik de gekoppelde tekstvakken dus alleen als ik met één keuzelijst werk, en ik aanvullende informatie wil laten zien uit die keuzelijst. Zodat de gebruiker altijd kan zien dat hij/zij de juiste waarde heeft geselecteerd. En bij aanpassen van de keuzelijst zie je uiteraard dan nieuwe waarden in de tekstvakken. Maar het kan/mag nooit de bedoeling zijn om die gegevens apart op te slaan.

 

[EdHa]

Het eerste deel van je reactie klopt met wat ik heb gedaan en bedoeld. We zijn het dus alvast voor 50% eens!
Waar je me kwijtraakt (of ik jou) is op het punt dat ik meerdere data of plaatsen als optie wil houden. Maar niet in de tabel evenementen, maar in de tabel klanten!!! Met andere woorden, in de tabel klanten wordt via een formulier een datum opgeslagen, of een naam evenement of een plaats. Op basis van die gegevens wordt de tabel evenementen 'gequeried' (als dat een goed woord is) en wordt vervolgens een evenement in de tabel klanten vastgelegd. Dat kan met de Id, eens.

Maar, de datum, de plaats en de naam van het evenement wil ik ook apart vastleggen, zodat de mogelijkheid om bijvoorbeeld de voorkeursdatum aan te passen en dan een nieuwe query op evenementen te draaien bestaat. Als ik die losse elementjes niet heb kan ik (1) geen query draaien op de evenementen maar moet ik uit een mogelijk lange lijst kiezen en kan ik (2) niet met een aanpassing van één van de elementen tot een andere keuze komen. Soms verandert er 1 element en blijven de andere ongewijzigd, dan moet er een nieuwe keus mogelijk zijn.

Ik hoop dat ik nu wel duidelijk ben. En anders moet ik een omweg zoeken.

Btw, ik kan een nieuw draadje openen met de volgende hiermee verband hebbende vraag: kan je een parameter afhankelijk maken van het al dan niet gevuld zijn van een veld? Dan zou nl een leeg veld geen parameter opleveren in een query en een gevuld wel. Als ik in de tabel klanten bv een gewenste datum heb kan die als formulieren!lijst!datum als parameter in de query op evenementen meewerken en als ik die niet heb is dat geen belemmerend criterium, snap je? Ik heb al geprobeerd met ifempty en zo, maar dat ging niet.

Het is niet helemaal hetzelfde onderwerp maar houdt er verband mee. Een nieuw draadje zou dus wel naar dit moeten verwijzen. Geen idee of dat kan.

 

[OctaFish]

Maar niet in de tabel evenementen, maar in de tabel klanten!!! Met andere woorden, in de tabel klanten wordt via een formulier een datum opgeslagen, of een naam evenement of een plaats.

Wat maak je me nou? Ben je bezig entiteiten door elkaar te husselen? Wat heeft een evenement met klantgegevens te maken? Ik zou eerst het ontwerp eens tegen het licht houden, want hier gaat m.i. iets heel erg fout!

 

[EdHa]

Ik begrijp je verbazing, maar hoop dat die verband houdt met het slechte voorbeeld. Maar om even in de sfeer te blijven: klantgegevens is meer dan naam, adres,woonplaats in mijn geval en omvat ook voorkeur voor evenement, beschikbaarheid op data enz. Hoe zou jij die dan opslaan? Ik snap dat je de klant aan het evenement koppelt en niet andersom, maar hoe leg je dan de genoemde gegevens vast die je nodig hebt voor het evenement? Of noem het evenement 'cursus' als dat makkelijker is. Het gaat mij om de vraag waar je wat vastlegt als het niet in de tabel klanten thuishoort en je het toch nodig hebt om tot een goede planning te komen.