Rij omzetten naar kolom

Voor een invulvakje wil ik de mogelijke gegevens ophalen uit een tabel. Voor de meeste gebruikers levert dat 1 mogelijkheid op, maar er zijn er die wel een tweede mogelijkheid hebben. (in de tabel velden registratienummer 1 en registratienummer 2)
Ik heb een query die keurig de gewenste gegevens levert, echter logischerwijze op een rij. Die rij moet dus voor een keuzeveld omgezet worden in een kolom. In Excel een eitje, maar ik Access?

Bedoeling is dus dat de meeste gebruikers automatisch het juiste gegeven ingevuld krijgen (keuzeveld met maar 1 optie) maar dat een aantal gebruikers de keuze hebben uit 2 registratienummers.

Handmatig invullen is natuurlijk een optie, maar ik probeer invulfouten zoveel mogelijk te voorkomen door keuzevelden.

Ik snap je werkwijze niet helemaal, en ook niet wat je nu als output wilt. Kun je een voorbeeldje maken? En hoezo is het in Excel een eitje? Bedoel je daar dat je met kopiëren en transponeren werkt? Dan heb je m.i. maar een half ei .

In de oorspronkelijke opzet hadden we een aantal locaties met allemaal 1 registratienummer. Eén locatie heeft een tweede locatie met een eigen registratienummer.
Voor selectie van een aantal zaken die via de dB lopen vraagt de dB nu gegevens van elders op met in de query voldoet aan regnr 1 of aan regnr 2.

In de loop der jaren is er steeds meer bijgekomen en nu moet elke locatie een bepaald rapport maken. Voor de locatie met 2 regnrs. worden dat 2 rapporten, voor elk reg.nr 1.
Nu moet er dus een rapport komen waarop dat reg.nr ook wordt ingevuld, alle overige gegevens zijn gelijk (nou ja, behalve huisnummer dan).
Om invulfouten te voorkomen wil ik dit via een keuzeveld realiseren, is het gelijk bij de meeste locaties goed ingevuld.

Maar voor die ene locatie moeten beide nummers dus in een kolommetje komen voor een keuze veld. (en ik wil het systeem flexibel houden want....... voor nu zou een knopje "gebruik alternatieve locatie" kunnen volstaan.

Ik snap wel ongeveer wat je wilt, maar niet hoe het is ingericht. Normaal gesproken zou je voor je registratienummers één veld gebruiken, omdat je daar immers ook maar één nummer aan koppelt. die nummers haal je blijkbaar uit een tabel, anders kun je geen keuzelijst gebruiken. Tenzij het maar een paar nummers zijn, en je een lijst met waarden gebruikt. Hoe dan ook: als je achteraf meerdere nummers wilt kunnen opslaan, dan kun je dat doen zoals je dat nu hebt gedaan, met twee velden, maar dat lijkt mij een slechte oplossing. Wat als er een derde nummer bijkomt? Begint het hele circus van voren af aan. Ik zou, zeker als het een beperkte lijst is, een veld met meervoudige waarden overwegen. (en dat doe ik niet snel ). Daarin kun je dan de gewenste nummer(s) aanvinken die je op wilt slaan. In een query kun je er dan voor kiezen om alle waarden in één veld te tonen, of voor elk veld een apart record te maken in de query. Die laatste optie zou jouw probleem in één keer oplossen.

Alternatief (en databasetechnisch gezien een stuk makkelijker en beter) is een koppeltabel maken waarin je per locatie de registratienummers opslaat. Dan heb je hetzelfde resultaat als je een query maakt.

Een derde registratienummer is er al, maar dat is "voor een andere tak van sport". ;-)
Oorzaak is dat als een bedrijf kadastraal gescheiden is van een andere afdeling ze beide een eigen registratienummer moeten hebben en sommige rapporten dan per registratienummer gemaakt moeten worden. Oorspronkelijk zagen we het als "gewoon" een afdeling tot een auditor daar niet mee akkoord ging. Kans dat één van de andere lokaties ook een tweede registratie krijgt is reëel (is er feitelijk al maar nog niet in de situatie dat de desbetreffende rapporten nodig zijn). Maar bij 2 registratienummers per lokatie, dan zitten we wel aan het max.

De huidige tabel bevat o.a. velden met locatienaam, regnr 1, regnr2 en een heleboel andere velden, NAW gegevens, lokatie instellingen e.d. Wat ik dus eigenlijk nodig heb is een kopie van die tabel gefilterd op lokatie met alleen die beide reg. nrs.
Is dat wat je bedoeld met een koppeltabel? Ga ik daar eens op googlelen (denk nu bij koppeltabel aan de gekoppelde tabellen naar de back end.)

Nee, dat is niet wat ik bedoel met een koppeltabel. Je hebt nu twee identieke velden ([Regnr 1] en [Regnr 2]) en dat hoort niet in een tabel, die is dan niet genormaliseerd. Die twee velden moeten dus weg (naar één veld) naar een andere tabel en die koppel je aan de oorspronkelijke tabel doordat je ook het sleutelveld laat terugkomen. Dan heb je dus een één-op-veel relatie tussen die twee tabellen en kun je meerdere reg nummers opslaan.

Oké, ik ga eens experimenteren. Probleem is wel dat de beide reg. nrs. herkenbaar moeten blijven als hoofd- en nevenvestiging. Vandaar ook de oorspronkelijke constructie met 2 velden. Vergelijk het maar met een tabel met privé tel, werk tel en mobiel.

Denk dat ik 't licht zie. ;-)

gekoppelde tabel, kolomtje voor de Id koppeling en kolom met omschrijving en een subformulier> werkt en toekomstbestendig. Bedankt weer.

Top! :thumb:

Het l...... is dat ik deze constructie al eens eerder gebruikt heb voor een veel complexer geheel (verrichtingen op patientkaart voor facturen) maar in dit geval omdat het "maar" om enkele gegevens ging niet aan deze constructie dacht.

Een database ontwerp is nooit afhankelijk van de hoeveelheid gegevens, maar altijd van de gewenste functionaliteit. Dus of je 20 records hebt of 20000, dat maakt voor de db niet uit. Kortom: altijd denken vanuit het FO .

Heb ik gemerkt. ;-) (al zou een optie om een rijtje om te zetten in een kolom best handig zijn af en toe).

Daar heb je een draaitabel voor . Of eventueel een functie maken.