hoofd en subvelden koppelen geeft geen geen getal maar id nummer

[Hendrik58]

Ik ben nu al een tijd bezig met access
en heb het volgende probleem met hoofd en subvelden
ik heb een formulier en daarin een subformulier welke gekoppeld zijn via hoofd en subvelden
maar nu komt het probleem
de velden die gekoppeld zijn moeten artnr. weergeven hoofdformulier doet het wel
maar het subformulier wil dat niet overnemen die geeft het id nr weer van het artikelnr.
wat doe ik verkeerd.

 

[namliam]

heb je de lookup wel toegevoegd in het subform?

 

[Hendrik58]

waar en hoe doe ik dat

 

[namliam]

je wil dan de id eerst veranderen naar een combobox (rechts klik er op en verander naar)
en dan de lookup instellen die je waarschijnlijk op je hoofdtabel al hebt...

Het is om deze (en nog vele andere redenen) een HEEL slecht idee om lookup's in je tabellen te definieren, het is vragen om problemen... Lookups doe je in forms.

 

[OctaFish]

Volgens mij heeft TS het over een keuzelijst op een formulier; hij praat althans niet over tabellen. Al hoeft het een het ander niet uit te sluiten.
Wat ik mij afvraag is wat de keuzelijst voor Artikelen op het hoofdformulier doet! Als je een bestellingenformulier bijvoorbeeld maakt, dan staan de Bestelgegevens op het hoofdformulier, en de bestelde artikelen (met ArtikelID) op het subformulier. Artikelen hebben in deze constellatie helemaal niets te zoeken op het hoofdformulierl! En ik kan eerlijk gezegd toch echt niet bedenken waneer je zowel op je hoofdformulier als in je subformulier een ArtikelID nodig hebt.

 

[Hendrik58]

Ik heb dus een hoofdformulier met tabbladen om een tabel met gegevens te vullen, en daarin ziet een subformulier (F_artikelinfo) deze is gemaakt van een tabel T_artikelen.
Vandaar uit wil ik, als ik iets in vul bijv. een serienummer en daarna vanuit een keuzeveld met invoervak, een artnr. selecteren. daarna kan ik dan de rest van de gegevens invullen op de desbetreffende tabbladen.
Maar als ik dus het artnr selecteer wil ik dat er in het subformulier een opsomming komt van wat er met dat artikel moet gebeuren.
en dat is nou het probleem als ik het hoofdveld niet koppel krijg ik wel een opsomming maar alleen van het eerste artnr. voor de rest gebeurd er niks omdat het niet gekoppeld is
als ik de boel koppel doormiddel van de artnrs. komt in het subveld alleen het id nr te staan van het desbetreffende art. en de rest is blanco.
Ik heb een database (access 2003) waarin het wel werkt maar in de nieuwe access 2013 krijg ik het niet aan de praat. ben er al dagen mee aan het stoeien.

 

[OctaFish]

Het wordt er met dit verhaal niet veel duidelijker op, vrees ik. Waarop is, om te beginnen, je hoofdformulier gebaseerd? Op de tabel [T_artikelen]? Of een query waarin die tabel ook zit? Ik vermoed het laatste, en dat het subformulier dan te koppelen is op basis van het veld [artnr]. Dan is het zeer logisch dat je bij het koppelen maar één artikel ziet in het subformulier, want er staat ook maar één artikelnr op je hoofdformulier. Dat is namelijk een enkelvoudig formulier met dus de gegevens van één record, met dus één ID. Je subformulier dat je baseert op [T_artikelen] kun je wel loskoppelen, maar dan zie je dus altijd alle records. Wat een onhandig gebruik is van een subformulier op een hoofdformulier. Maar van deze zin:

Maar als ik dus het artnr selecteer wil ik dat er in het subformulier een opsomming komt van wat er met dat artikel moet gebeuren.

snap dus ook weer helemaal niks... Overigens wel vreemd dat de db in 2k3 wel werkt, en in 2013 niet, want ik vermoed dat er dan iets heel anders aan de hand is. Nog afgezien van de vraag of je db wel of niet logisch in elkaar steekt . Was ook handig geweest als je die informatie gelijk had gegeven, want dan kunnen we het probleem op de goede plek zoeken.

 

[Hendrik58]

Ik doe het bestand wel als bijlage erbij misschien wordt het dan duidelijk
staat op formulier F_metingen

 

[Hendrik58]

Het is me toch gelukt
Heb sommige tabellen opnieuw gemaakt en beter gelinkt met de tabellen onderling.
Bedankt

 

[OctaFish]

Als ik een voor mij onbekende database open, dan is het eerste wat ik doe het venster <Relaties> openen om te zien hoe de db in elkaar zit. Het zal je wellicht niet verbazen dat ik behoorlijk schrok van die van jou. En dan hebben we het natuurlijk vooral over de tabel [Metingen], die bijzonder slecht (zeg maar gerust: niet) is genormaliseerd. Ik zag dat al voordat ik ook maar één veld uit die tabel had bekeken, omdat je in de Relaties zo'n 8 keer de tabel [Produktie medewerkers] daaraan had gekoppeld. Normaal gesproken zou je aan één keer genoeg moeten hebben. Maar als je in één tabel velden gaat herhalen, dan maak je het jezelf behoorlijk moeilijk. Een simpel voorbeeldje is het veld [Datum_emailleren_1elaag], dat in 3 varianten terug komt. Je zou dat veld in een aparte tabel [Emailleren] kunnen zetten, met daarin één datumveld, een veld [Medewerkers_Id] en een veld [Laag] waarvan je in het (dan) subformulier Emailleren keuzelijsten maakt. Al hoeft dat veld [Laag] niet eens, want zodra je een laag uitvoert, en dus een datum+tijd hebt ingevoerd, weet je welke laag dat is: de oudste datum = Laag1, de volgende datum =Laag2 en zo verder. Op die manier is niet alleen het veld [Datum_emailleren_1elaag] t/m [Datum_emailleren_3elaag] weg genormaliseerd, je bent ook van de beperking af dat je nooit meer dan 3 lagen kunt emailleren. Mocht dat nodig zijn.
Veel erger is de situatie met de velden [Laagdikte2bisq1_1] t/m [Laagdikte2bisq1_7], Laagdikte2bisq2_1] t/m [Laagdikte2bisq2_7] etc, die dus ook allemaal naar een eigen tabel kunnen. Als alle cijfers duiden op één meting, dan kun je ze bij elkaar rapen en er één tabel van maken. Zelfde voordeel: heb je 3 metingen nodig, dan maak je 3 records, wil je er 9, dan maak je 9 records. Geen beperkingen meer.
Verder maak je ook nog gebruik van keuzelijsten met invoervak (goed ingeschat namlian :thumb en dat is iets waar ik ook een gruwelijke hekel aan heb. Ik zeg: nooit doen!

Kortom: toch graag wat meer uitleg.

Terug naar de vraag: ik snap 'm jammer genoeg nog steeds niet... Ik zie een formulier (F_metingen) met een subformulier. Geen tabblad te bekennen....

Laat de uitleg dus maar zitten

 

[namliam]

Ja, zie je, je had in je Artikel tabel de kolom niet als Lookup gedefinieerd waardoor het op je formulier er anders uit kwam....

Op zich is het beter om in de tabellen GEEN lookups te doen, kost behoorlijk in je performance en kan allerlij problemen geven in de toekomst

Verder zijn er diverse design issues met je database.... Zodra je kolommen hebt met 1,2,3,etc of 1e,2e,etc dat vraag meestal (99+% van alle gevallen) om een nieuwe normalisatie slag met als gevolg een extra tabel ...

Edit: zie dat Octafish mijn mening over je database deelt

 

[Hendrik58]

Het gaat om het unieke serienummer waar alles aan hangt en het product wordt 3 maal bewerkt met 3x 5 meetwaarden en door verschillende medewerkers die ik dus selecteer uit een tabel vandaar die koppelingen vanuit de tabel, dit is me zo geleerd om te doen. Ik ga dus vanuit de tabel met de wizard opzoeken naar die tabel en dan krijg je die koppelingen zo, of doe ik iets geks, of moet ik de integriteits modus uitlaten.
En keuzelijst met invoervak vind ik niet gek ik moet later in het formulier het unieke nummer kunnen zoeken en dan komt alles tevoorschijn wat er achter het nummer zit.
Dus ik vond het zo gek nog niet, maar nu ik dit lees ben ik daar niet zo zeker meer van. Maar goed ik leer elke dag bij dus nu ook, ik zal proberen om de database zo te maken dat het voor mij werkt en dan post ik hem nog
en dan wil ik graag horen wat er dan fout aan is.
verbeteringen zijn altijd welkom graag zelfs.

BVD Hennie

 

[namliam]

Hennie,

In normalisatie probeer je o.a. repeterende kolommen te voorkomen... In jou geval repeteren de meetwaarden o.a. maar gemiddeld genomen zou het verstandig zijn als alle kolommen waarbij je bijvoorbeeld als je contact gegevens van een bedrijf vast legt, en je weet nooit hoeveel contacten je krijgt bij een willekeurig bedrijf maar zelfs als je het wel zou weten.... krijg je dus iets als....
Contact1, Contact2, ... Contact 10
Functie1, Functie2, ... functie 10
Telefoon1, Telefoon2, ..., Telefoon 10

In plaats daarvan zou je een extra tabel maken met 4 kolommen, BedrijfsKey, Contact,Functie, Telefoon
En dan zou je in die table zoveel records krijgen als dat je contacten hebt, 1, 5, 10, 100, 1000 maakt dan niet meer uit.
Verder maakt het in gevallen van meetwaarden oid het makkelijker om gemiddelden te berekenen en met datums doorloop tijden te berekenen....
Het zijn maar zeer zeldzame gevallen dat je de normalisatie regels kiest te negeren en een oplossing maakt die hier niet aan voldoet... Zeker iets om GOED over na te denken.

Een keuzelijst met invoervak is prima, op een FORMULIER... NIET in een tabel.... CRUCIAAL verschil, het kan wel, werkt ook, maar gaat je hoofdpijn bezorgen in de toekomst

 

[Hendrik58]

Ik ben nu een stukje verder met mijn database en hij is nog lang niet af maar
ik heb verschillende tabellen
Metingen2 t/m5
produktiemedewerkers
produktiemiddelen
leveranciers
enz.
Maar in de tabel metingen komen alle waarden in te staan van 5 produkten die op dezelfde manier gemaakt worden. vandaar ook die repeterende records, ander hou ik de boel niet uit elkaar.
maar in die tabel metingen moet ik wel verwijzen naar andere tabellen. bijv door wie wordt het gemaakt door welk apparaat gestraald enz.
en dat komt 3x per te maken laag voor. en dat verwijzen doe ik dus met die wizard opzoeken en dan krijg je in de tabel een record met nummeriek veld.
Vanuit een formulier vul ik die tabel.
In dat formulier komen al die records te staan van de tabel
En sommige velden zijn keuze lijst met invoervak omdat ik een medewerker moet kiezen of iets dergelijks.
En ik werk met een Schakelbord om vandaaruit te werken met formulieren en rapporten etc.
Andere mensen gaan met deze database werken, vanuit dit schakelbord.
die zien de tabellen niet eens, die zien knoppen met informatie erop waarop ze kunnen klikken en dan kunnen ze via een formulier alle gegevens invullen
wat achter dat uniek eenmalige serienummer komt te hangen.
Ik ben van plan om 5 tabellen te maken die innerlijk identiek zijn maar die alleen een andere naam hebben om de gegevens van die 5 produkten vast te kunnen leggen.
Ik wilde dat eerst in een tabel doen maar dat wordt zo onoverzichtelijk, vond ik want je hebt 5 produkten die per laag 15 maal gemeten moeten worden met daaraan gekoppeld informatie van waaruit
die laag is opgebouwd en door wie en wat enz.
en dat 5 maal dat werd me te lang, en te moeilijk met de namen.
Dit ter uitleg..
Moet ik dus tabellen maken en in de tabel gewoon een record maken en zeggen oke jij bent tekst jij bent nummeriek, jij bent memo, enz.
en niet verwijzen naar andere tabellen.
of hoe ??

graag uitleg

 

[namliam]

Normalisatie... Een 5 product type is net 5 tabellen, 5 product is niet 5 kolommen, 15 metingen is geen 15 kolomen, en 5 producten met 15 meetingen is ZEKER niet 75 kolommen.
Je maakt een tabel:
Product, MetingNummer (discutabel), MetingType (Indien van toepassing)MetingGedaanDoorWie, MetingDatum, MetingWaarde
Daar moet je eventueel nog een Key en een Foreign Key bijvoegen.... en eventueel nog meer dingen die toe te wijzen zijn aan de meting.

Neem even voor het gemak aan dat je weet wat een Key en Foreign Key zijn
Kijk anders eens op de wiki om een idee te krijgen: http://nl.wikipedia.org/wiki/Databasenormalisatie