keuzelijst met meerdere uitvoervelden

[mm_the_matrix]

hallo,

ik heb een constructie... waar men een product aan een abonnement koppeld... nu was mijn idee om dat een abonnement een id heeft en een volgnr... namelijk een abonnement kan op meerdere manieren worden gevuld... daarom het volgnr...

wat wil ik... een keuzelijst in het formulier product waar naar het abonnement en volgnr gewezen wordt... dit kan ik zelf wel... en dat werkt alleen kan ik dan maar 1 veld vullen namelijk abonnement (in product) of volgnr (in product) is het mogelijk om een keuzeveld een uitvoer veld te laten zijn voor zowel het abonnement als het volgnr.

ter overzichtelijkheid van het abonnement formulier wil ik graag dat het volgnr per abonnement opnieuw begint... daarom kan ik de regel niet uniek maken met alleen een volgnr

 

[Bartuls]

Ik snap je vraag niet helemaal.
Als je met de wizard een nieuwe keuzelijst (listbox) op een formulier zet dan kun je daar zoveel kolommen in aanmaken als je wilt.
Kun je misschien je vraag anders formuleren?

 

[mm_the_matrix]

ok....

je ken met een listbox een waarde bepalen uit een ander formulier / tabel / query

hiervoor kun je dus die listbox een aantal extra velden meegeven om het duidelijker te maken (naast product id: omschrijving merk type)

maar nu het probleem, aan het einde van die wizzard vraagt access naar welk veld wilt u de gevonden resultaten invoegen...

en om dat invoegen gaat het me nu net... ik wil graag het product id van het abonnement en het volgnummer invoegen dus 2 velden en niet 1

 

[Bartuls]

Dat kan ook niet. Een listbox heeft 1 waarde als uitvoer (dat is de waarde je in je code krijgt als je me![MijnListbox] gebruikt).
Ik kan je zo geen oplossing geven omdat ik je datamodel niet ken.
Post je mdb (winzip, geen winrar) en vertel even waar het precies zit, dan kan ik je misschien verder helpen.

 

[mm_the_matrix]

als het niet kan dan houd het een beetje op...

we hebben een analyse gedaan met fco-im, daaruit komt dan een datamodel.
dat inporteren we in access en de tabbelen structuur is gedaan.
daarna wil je eigelijk de structuur niet meer veranderen.

ik heb nu de db veranderd dat in het producten het veld abonnement een samenvoegsel is van abonnement id en volgnr... maar er zit nu dus wel een gat in onze analyse... omdat dit een workaround is in access maar niet in een echte analyse

 

[Bartuls]

Jullie hebben een klassieke fout gemaakt.
Analyse fco-im geeft als eindresulataat een logisch datamodel.
Alvorens je de tabellen in access maakt moet je van dit logische datamodel eerst een technisch datamodel maken. Tijdens dit proces ga je kijken wat je in je datamodel moet aanpassen om de te realiseren functionaliteit technisch mogelijk te maken.
Als je die stap overslaat dan loop je uiteindelijk tegen dit soort problemen aan.
Ik hoop voor jou dat het abonnement veld geen sleutelveld is, als dat wel het geval is heb je er weer uitdaging bij.

 

[mm_the_matrix]

je mag toch niet zomaar je datamodel veranderen... ik neem aan dat u fco-im kent...

de structuur en inhoud van het datamodel wordt direct bepaald in interviews met de klant. er kan nadien niet vanafgeweken worden aangezien men dan de analyse net zo goed niet had kunnen doen. wel hebben we in de analyse bij de interviews al rekening gehouden met belemmeringen (zoals het ontbreken van dubbele sleutels)... case talk levert een inportscript aan die geimporteerd kan worden in access... (eventuele problemen worden daar al uitgehaald)

in de praktijk zou u gelijk kunnen hebben... alleen is er dan wel wat misgegaan bij de analyse zelf... men had daar ook toen rekening mee kunnen houden

 

[Bartuls]

Ik ken fco-im goed.
Het grote manko van dit gereedschap is dat het geen onderscheid maakt tussen een functioneel datamodel en een technisch datamodel.
Het direct technisch implementeren van een functioneel datamodel levert in de praktijk nagenoeg ALTIJD problemen op bij technische implementatie.
De export functionaliteit van fco-im naar access houdt wel rekening met de wensen van access, maar doet geen technisch ontwerp voor je.

Tijdens de migratie van een functioneel datamodel naar een technisch datamodel moet je wel binnen de in de voorgaande fase vastgestelde grenzen blijven, maar mag je wel om technische redenen velden of tabellen toevoegen. Dat doe je dan om technische implementatie van bepaalde aspecten mogelijk te maken of om de performance te kunnen waarborgen. fco-im houdt met dat soort zaken geen rekening.

suc6