Zoeken in verschillende velden in dezelfde tabel (ACCESS)

[gast0451]

Hallo allemaal,

Ik hoop dat iemand mij kan helpen.

Ik heb een database (een reparatie overzicht) waarin een tabel staat met diversen velden.
Veld ONDERDEEL, Veld DATUM, Veld 2000. 2001, (enz. t/m 2013)
Een aantal van die velden zijn zoals gezegd zijn velden met jaartallen (2000 - 2013) welke d.m.v. aanvinken [v] (ja/nee) geactiveerd worden.
Hieraan kan ik zien in welk jaar een reparatie heeft plaatsgevonden en... indien van toepassing er in het verleden mogelijk al eerder een reparatie heeft plaatsgevonden.
Ik heb nu een query waarin ik zie welk onderdeel er in een bepaald jaar is gerepareerd.
Dit door in de query het veld aan te geven (bijv. 2013) en de optie WAAR (alle andere velden worden indien gewenst weergegeven)
Nu wil ik graag d.m.v. een query en het intypen van het jaartal zien welke onderdelen er in dat jaar zijn gerepareerd. Daarmee kan ik dan een rapportje draaien.
Maar ik krijg (tegelijkertijd) zoeken in verschillende velden niet voor elkaar.
Er moet dus gekeken worden of de hokjes (vinkjes) aan staan (JA/NEE) en dan alleen deze records weergeven in een query of rapport, maar dan wel d.m.v. het 'ingeven' van het jaartal en niet met een vooringestelde query.


Misschien denk ik te complex?
Misschien is het complex?

Hoop dat ik het een beetje goed heb kunnen uitleggen.

Wie kan en wil mij helpen?

Alvast bedankt.

Luke

 

[OctaFish]

Je tabellenstructuur zou eerst aangepast moeten worden, want dit is een hele ongelukkige opzet. De velden 2000 t/m 2013 zijn namelijk totaal niet nodig, en maken je probleem nodeloos ingewikkeld. Waarom? In je tabel Reparaties heb je ongetwijfeld een veld [AanmeldDatum], en een veld [DatumAfgemeld]. En het leuke van datums is: als je een datum weet, heb je het jaartal er gratis bij . En de maand, mocht je daar ook op willen rapporteren. Als je het in je vraagstelling al over die tabel hebt ([reparatie overzicht]?) dan zit daar al één datumveld in, dus dat kun je prima gebruiken. Dus wat moet je dan nog met die jaartallen? Bovendien is het natuurlijk heel vreemd als een reparatie in zowel 2003, 2009 en 2012 is uitgevoerd. En dat kan, want elke gebruiker kan een jaar aanvinken. De jaartallen hebben dus geen enkele reparatie met wat ze zouden moeten hebben: het jaar waarin de reparatie daadwerkelijk heeft plaatsgevonden. Kortom: begin eens met die velden weg te gooien!

 

[gast0451]

Bedankt voor je snelle reactie Michel.

Ter info en alle respect naar de lezers (wil zeker niet vervelend overkomen, maar duidelijk (porberen) te zijn)

Een reparatie kan wel degelijk meerdere keren op een (zelfde) onderdeel (klep) plaatsvinden (in verschillende jaren wel te verstaan).
Een reparatie hoeft niet te betekenen dat een onderdeel wordt vervangen.
Dat het ooit tijd wordt om deze te vervangen is een ander verhaal en nu niet relevant (op dit forum wel te verstaan), maar wel handig voor mij, want te vaak repareren is (mogelijk) te duur.
Door de database kan ik dat beter inzichtelijk maken (het gaat hier om een verloop van de afgelopen dertien jaar en verder de toekomst in.

Dan wat betreft de datebase.

Enerzijds is het wegdoen van die velden geen probleem hoor, anderzijds wil ik wel kunnen zien door het ingeven van een jaartal welke 'klep(pen)' er gerepareerd is (zijn) en dus in welke jaren.
Als je mij kan vertellen met welke criteria ik dat kan aangeven. Bijv. met Like [] ?? (zonder wildcards zoals * en/of ?)
Datums zijn bekend idd. maar hoe zoek ik op een 'deel' van die datum?

gr.

Luke

 

[OctaFish]

Eén reparatie, heeft hoe je het ook wendt of keert, nooit een duur over verschillende jaren. Tenzij je je werk héél erg slecht doet. Als ik mijn auto naar de garage breng voor een storing in 2007, en ik krijg hem pas in 2013 terug, dan kunnen ze een rijk gedocumenteerde klacht tegemoet zien. Dat een apparaat meerdere keren op hetzelfde onderdeel moet worden gerepareerd, dàt wil ik wel geloven. Maar dan maak je voor elke reparatie een eigen record aan. Ik beheer zelf een incidentenprogramma, en dat werkt echt met individuele incidenten/meldingen. Dat je daar wel of niet onderdelen aan hangt, boeit eigenlijk niet eens, maar dat doe je per melding. Door de tabellen op de juiste manier aan elkaar te koppelen, kun je verschillende overzichten maken, zoals:
1. aantal meldingen (eventueel per merk/afdeling etc) per maand, jaar, kwartaal, zelf in te geven periode etc.
2. aantal meldingen op basis van een apparaat, al dan niet met kosten/vervangen onderdelen etc.
3. gemiddelde duur van een type reparatie, uitgesplitst op apparaat, onderdeel, etc.

Kortom: door je db in de juiste structuur op te zetten, kun je alle rapportages maken die je maar wilt. In elke vorm die je maar wilt. En jouw opzet is daar totaal ongeschikt voor. Ik heb sterk het vermoeden dat er geen functioneel ontwerp aan de database ten grondslag ligt, en dat jullie eerst zijn gaan bouwen, en vervolgens tot de conclusie zijn gekomen dat er straks allerlei velden bijmoeten, want je bent nog niet voorbereid op 2014 om maar eens wat te noemen. Tenzij je meer weet dan de rest van de mensheid, en de wereld op 31 december ten onder gaat

 

[gast0451]

Dank voor je reacties.
Ik zoek even verder.

gr.

Luke

 

[OctaFish]

Misschien denk ik te complex?
Misschien is het complex?
...
Wie kan en wil mij helpen?

Ik probeer je te helpen. En dat is dus niet een antwoord geven op het huidige probleem, want dat probleem wordt alleen maar lastiger en groter. Ik zou geen energie steken in het zoeken naar een oplossing voor deze specifieke vraag, maar eerst de tabellen normaliseren. Uiteindelijk ben je daar veel beter mee geholpen dan nu met een noodverbandje.
Al staat het iedereen natuurlijk vrij om je daar verder mee te helpen