Meerdere tabelkolommen met zoekwaarde tonen op formulier

Status
Niet open voor verdere reacties.
OctaFish zei:
ProjectWerkzaamheden kan gewoon met één sleutelveld af (je Autonummerveld). Als je mijn bijdragen niet leest (#33) dan wil ik best afhaken, want dan vind ik het zonde van mijn tijd :).
Volgende probleem: de velden Preo_klantnaam en PW_KLantnaam moeten gewoon weg, die horen niet in die tabellen. Net als PW_Projectnummer. Haal alle overbodige velden weg uit je tabellen, en je komt een stuk verder.
Klik om te vergroten...

Het is niet mijn intentie geweest dit te negeren :eek:

Zoals ik het nu begrijp creëer ik bij mezelf dus de verwarring door alle gegevens in elke tabel te willen plaatsen. Voldoet het dan om de einge sleutel in tabel Projectwerkzaamheden te koppelen met de sleutels van de 2 naastliggende sleutels? dus als volgt?

Pro_ID --- PW_ID --- Pw_ID

Ik kan het momenteel even niet testen :confused:
 
Als je in Brontabel A een sleutel hebt van één veld, en in Brontabel B ook, dan heb je in de tabel TabelA_TabelB een eigen sleutel (TabelA_TabelB_ID), en een veld TabelA_ID en een veld TabelB_ID nodig voor een juiste koppeling. Je tabel Werkzaamheden_Medewerker vind ik overigens wel heel summier; zelf zou ik daar bijvoorbeeld ook een startdatum-einddatum in zetten (elke werkzaamheid heeft zijn eigen uren tenslotte), en wellicht ook nog wat andere details die op de bezigheid betrekking hebben. En de tabel [Status] hoef je maar aan één tabel te knopen, niet aan twee. Dat je die tabel óók in [Projectwerkzaamheden] gebruikt houdt niet automatisch in dat hij daar ook aan gekoppeld moet zijn. Je vult hem vermoedelijk middels een Keuzelijst (met invoervak), dus het is al licht onmogelijk om andere waarden te selecteren dan er in de lijst zitten.
 
Zeer duidelijk verhaal. Ik hoop dat ik er vanmiddag mee bezig kan en dat alles een beetje op zijn plaats valt :)

Aldoende leert men. Nu eenmaal uitgelegd, is mij het verhaal van sleutels ook duidelijker. Youtube en Microsoft-filmpjes helpen heel wat, maar ik ben blij met de ondersteuning die ik hier vind. Langzamerhand wordt het wel wat. Ik heb een goed gevoel over dat het allemaal wel goed komt (Had mij dat gisteravond niet gevraagd :D)

To be continued
 
OctaFish zei:
Als je in Brontabel A een sleutel hebt van één veld, en in Brontabel B ook, dan heb je in de tabel TabelA_TabelB een eigen sleutel (TabelA_TabelB_ID), en een veld TabelA_ID en een veld TabelB_ID nodig voor een juiste koppeling. Je tabel Werkzaamheden_Medewerker vind ik overigens wel heel summier; zelf zou ik daar bijvoorbeeld ook een startdatum-einddatum in zetten (elke werkzaamheid heeft zijn eigen uren tenslotte), en wellicht ook nog wat andere details die op de bezigheid betrekking hebben.
Klik om te vergroten...

Is het niet zo dat ik dan de tabellen die beginnen met een @ alle 3 kan voorzien van maar één sleutel? Die had ik in gedachten als koppeltabel namelijk. Hieronder valt ook de tabel Werkzaamheden_Medewerker, wat denk ik verduidelijkt dat de tabel Projectwerkzaamheden de eigenlijke tabel is waar de werkzaamheden in komen te staan.
 
Ja, mits de velden KP_ID, PW_ID etc. uniek zijn. Met een Autonummer is dat altijd zo, dus dat is in essentie genoeg als sleutel. Je mag ook een sleutel maken van KP_KLant_ID en KP_Project_ID; dus van twee velden. Als je een autonummerveld gebruikt, hoeft dat dus niet, maar ik zou wél een index maken van die twee velden om te voorkomen dat je twee keer dezelfde combinatie van KP_KLant_ID en KP_Project_ID toevoegt. Want dat mag natuurlijk niet. Geldt ook voor je andere tabel. Ik weet eerlijk gezegd niet of het gebruik van een @ in een tabelnaam nu heel erg handig is; zelf zou ik dat nooit doen. Is ook nergens voor nodig, lijkt mij.
 
Ben alleen maar verder van huis nu :(

Wanhoop.png

Wanneer ik nu een formulier aanmaak met klanten, hierin een subformulier met projecten en daar weer een subformulier met werkzaamheden gaat het nog niet goed... Ik wil graag meerdere werkzaamheden toevoegen aan de betreffende order en vervolgens krijg ik de volgende melding:

huh.png

Snap er niks meer van.
 
Je hebt je sleutels nog niet aangepast. Wellicht zit daar het probleem.
 
Overigens zie ik dat je in de tabel ProjectWerkzaamheden nou nét de twee velden hebt weggegooid die je nooit had mogen verwijderen :).
 
OctaFish zei:
Overigens zie ik dat je in de tabel ProjectWerkzaamheden nou nét de twee velden hebt weggegooid die je nooit had mogen verwijderen :).
Klik om te vergroten...

Dit was inderdaad een domme zet. Weer terug gebracht naar oude situatie... Volgens mij weet ik nu ook wat je bedoelde met het aanpassen van de sleutels. Verder nog een paar aanpassingen gedaan. Een klant kan bijvoorbeeld wel meerdere projecten plaatsen, maar elk project hoort maar bij 1 klant. Huidge stand:

stand160620.png

Middels queries krijg ik nu wel de juiste gegevens, maar het feest houdt op bij de projecten. Hoe leg ik nu de lijntjes tussen Project en Werkzaamheid? Ik dacht dat ik er wel van af kwam met een 1-op-veel relatie, maar dit gaat niet goed (kan geen relatie maken waarvoor referentiële integriteit moet worden afgedwongen).
 
Als je geen relatie kan leggen tussen ProID --> PW_ProjectID, en/of PW_ID --> PW_WerkzaamheidID dan komt dat doordat er niet-gerelateerde data zit in de tabel ProjectWerkzaamheden, ofwel de types komen niet overeen. Het laatste is simpel op te lossen, het eerste alleen als je de wizard "niet-gerelateerde data" gebruikt om te kijken welke records er in PW_Werkzaamheden zitten waarvan ofwel de PW_ProjectID niet bestaat in Projecten, ofwel PW_WerkzaamheidID niet in Werkzaamheden. Dat moet je dan dus eerst oplossen.
 
Ik wilde het proberen zonder de koppeltabel Projectwerkzaamheden. De koppeling tussen de door jou genoemde gegevens lukt wel. Echter krijg ik dan het probleem dat ik geen werkzaamheden kan toevoegen aan orders. Ik ben er alleen nog niet uit waarom niet...
 
Die koppeltabel is noodzakelijk, want je hebt een relatie tussen Projecten en Werkzaamheden. Type: veel-op-veel (meerdere projecten kunnen meerdere werkzaamheden bevatten). Ik zie geen tabel Orders, en mij lijkt het dat aan een order geen werkzaamheden hangen. Die hangen immers aan projecten? Of is een order een project?
 
Orders zijn in dit geval projecten. Ik dacht zelf ook aan veel-op-veel tussen projecten en werkzaamheden, maar het kan toch ook één-op-veel? Aangezien elke order al uniek is, meerdere werkzaamheden kan bevatten en maar 1 keer kan voorkomen per order?

Volgens mij heb ik de boel nu wel goed draaiende met een één-op-veel relatie, maar moet als ik tijd heb nog even uitgebreider testen.

Waar ik verder wel tegenaan liep is dat ik een scherm wil maken waarin de werknemers bij de werkzaamheden vermeld zijn, echter krijg ik daar de sleutel te zien ipv de naam (berekende rij). Dat zal ik nog op moeten lossen.
 
Het is aan jou wat je precies wilt. Een vastgelegde handeling (activiteit) die je hergebruikt, moet via een veel-op-veel. Als het Top-down is, kan het ook met één-op-veel. Als een projectactiviteit uit meerdere werkzaamheden bestaat (voorbereiding, ontwerpfase, bouwfase, implementatie, evaluatie etc) dan zit je met veel-op-veel. Het is aan jou om te bedenken wat de processen zijn, en hoe je die vastlegt. Wij kunnen hooguit zeggen of het goed is of niet :).
 
Dan denk je er bijna te zijn en de gegevens juist in beeld te hebben, komt er weer een andere dingetje boven drijven :rolleyes: Ik heb een formulier gemaakt met subformulieren, waar ik de data juist in beeld krijg. Een hele prestatie op zich :d Echter nu doet het probleem zich voor dat ik geen nieuwe werkzaamheden kan toevoegen aan een order in dit scherm. Volgens mij komt dat doordat ik in het betreffende subformulier geen order identificeer. Bestaande werkzaamheden kan ik wel aanpassen (andere omschrijving / andere medewerker)...

Dit is het betreffende formulier:
Vraag2.png

De bron van het tweede subformulier is een query die er als volgt uitziet:
Query.png

En mijn relaties zien er nu zo uit:
Relaties.png

Heeft dit nu te maken met een van de relaties, of is mijn query/subformulier corrupt of incompleet? Of is er een mogelijkheid een formulier te maken waar ik deze gegevens wel kan aanmaken?
 
Laatst bewerkt:
Nog een kleine toevoeging:

Ik kan wel een nieuw formulier maken waarbij ik de werkzaamheden in projecten kan aanpassen en toevoegen, wat ik graag wil. Maar ook hier geldt: Dan kan ik geen nieuw project aanmaken omdat ik de klant niet kan selecteren :( Komt dit er op neer dat ik dat ik geen gegevens kan aanmaken in een "bovenstaande" tabel, ondanks dat de koppeling er wel is?

Wzh Toevoegen.png
 
Op basis van je plaatjes is er niks van te zeggen. In bericht #56 zit een plaatje met de relaties. Alle gelegde relaties die géén Referentiële Integriteit hebben, zijn volkomen nutteloos en waardeloos. Je kunt bijvoorbeeld net zo goed WzhAfdeling aan PW_Begindatum koppelen, die is net zo relevant als de huidige tussen de velden WzhID en PW_Omschrijving. Als je geen RI kunt vastleggen, dan klopt er dus iets niet aan de gebruikte velden. Ofwel ander type, ofwel ontbrekende data. Hoe dan ook: de huidige relatie kun je net zo goed weggooien.

Eén van de belangrijkste oorzaken dat je geen records kunt toevoegen, zit 'm in het gegeven dat je de verkeerde velden zou kunnen gebruiken. En dát is dus iets dat we nu niet kunnen zien, daarvoor hebben we de db nodig.
 
Hierbij de huidige stand van zaken. Ik hoop dat het euvel eenvoudig te vinden is...
 

Bijlagen

  • Planning19062020 TEST.zip
    722,6 KB · Weergaven: 44
Dag Littlefarmer,

aangezien alle projecten terug één voor één opgestart worden heb ik momenteel niet zoveel tijd. Mijn excuses als ik daardoor de beloofde hulp niet heb kunnen geven.
Relaties zonder referentiële integriteit kunnen wel degelijk hun nut hebben. Volgende week kan ik waarschijnlijk terug wat meer tijd vrijmaken voor andere dingen. Als het nog nuttig is zal ik dan eens naar je voorbeeld kijken. Wel één vraag: kan één project verschillende klanten hebben of is er per project slechts één klant. Indien het laatste, dan kunnen we de structuur wel wat vereenvoudigen.
 
Status
Niet open voor verdere reacties.
Steun Ons

Nieuwste berichten

Terug
Bovenaan Onderaan