access relaties

Status
Niet open voor verdere reacties.
B

baws

Terugkerende gebruiker
Lid geworden
9 apr 2010
Berichten
1.258
ik heb een database met 2 tabellen met een deel dezelfde gegevens.
hoe kan ik ervoor zorgen dat als ik bijvoorbeeld de datum van betaling in tabel1 heb ingevoerd dat die ook in tabel 2 wordt bijgewerkt?
ik gok dat het met relaties te maken heeft.
van relaties snap ik nog niks in access iemand een korte samenvatting wat ze doen?
met vriendelijke groet
 
Laatst bewerkt:
Allereerst maak je al een denkfout. Je moet in een database informatie nooit 2 keer opslaan. Dit is nou juist de reden dat je een database gebruikt. Geen dubbeling van informatie.

Hiervoor gebruik je inderdaad relaties. Dit zijn niks anders dan koppelingen tussen velden in tabellen. Een voorbeeld. Stel je hebt een database met 2 tabellen. 1 tabel bevat de voorraad. Een tweede tabel de verkopen. Je kunt dan bijv. een relatie leggen tussen het artikelnummer van een artikel. Verkoop je nu een artikel dan voeg je een regel toe aan de tweede tabel. Deze bevat dan minimaal het artikelnummer, maar ook eventuele verdere details (datum, tijd, prijs).
 
Je legt relaties tussen tabellen om ervoor te zorgen dat je de juiste gegevens in een tabel opslaat. Simpel voorbeeld: in een tabel Verhuur leg je vast welke klant welke film huurt. Om te voorkomen dat je fims verhuurt aan niet-bestaande klanten, leg je een relatie tussen het veld KlantID in de tabel Klanten, en het veld KlantID in de tabel Verhuur. Daarbij zorg je ervoor met de optie <Referentiële Integriteit> dat je geen KlantID's in Verhuur kunt invoeren die niet bestaan in Klanten. Als je nu een record toevoegt aan Verhuur, en het KlantID bestaat niet, dan krijg je een foutmelding, en kun je het record niet opslaan.

Relaties kun je niet gebruiken om automatisch gegevens van tabel1 naar tabel2 weg te schrijven. Daarvoor moet je (bijvoorbeeld) toevoegqueries, of Bijwerkqueries gebruiken, afhankelijk van wat je aan het doen bent. Meestal regel je die acties op een formulier, waar je dan een knop maakt die de gegevens opslaat.
 
hoe kan ik dan zorgen dat dat als ik in tabel 1bijvoorbeeld een product toevoeg die automatisch een product code krijg dat die producte code ook in tabel 2 komt te staan automatisch.
nee ik hoef niks anders alleen dit voorbeeld.
 
ok sorry ik was te laat.
maar kan ik dan via een formulier, die heb ik wel al een paar. 2 besturingselementen aan koppelen.
1 vanuit tabel 1 en 1 vanuit tabel 2

mvg
 
Wat sla je op in Tabel1 en wat in Tabel2?
En wat is de relatie tussen die twee tabellen?
 
tabel1 factuur
tabel2 betaling

tabel1
productnummer
datum factuur
datum vervalling
product

tabel2
productnummer
betaald
datum betaling
datum vervalling
 
Ik vind de structuur niet heel erg handig, ik zou zelf meer in deze richting werken:

Code: 
tabel1 factuur
tabel2 factuurregels
tabel1
FactuurID        (Autonummer)
FactuurDatum     (Datum/Tijd)
BetaalTermijn    (Numeriek)
BetaalDatum      (Datum/Tijd)
Volgende veld is niet nodig, want als je een betaaldatum hebt, is er betaald... Tenzij je een overall check wilt, bij losse betaaldatums bijvoorbeeld.
Betaald          (Ja/Nee)
tabel2
FactuurRegelID   (Autonummer)
FactuurID        (Numeriek) (Komt uit Factuur)
RegelNr          (Numeriek) (verhogen bij elk artikel in factuur, begint elke factuur bij 1)
ProductNummer    (Numeriek ?) (Kan ook tekst zijn)
Aantal           (Numeriek)
Als je per artikel de betaaldatum wilt bijhouden:
BetaalDatum      (Datum/Tijd)
In dit voorbeeld heb je dus een relatie tussen Factuur en FactuurRegels. Voor een factuur die niet bestaat maak je natuurlijk geen factuurregels aan. En omgekeerd...
De reden dat ik geen Vervaldatum gebruik, is dat je die kunt afleiden uit de FactuurDatum + de Betaaltermijn. Die kun je bijvoorbeeld opslaan in je klanten tabel, zodat je voor elke klant aparte betaalafspraken kunt maken.
 
het is makkelijker op termijn omda tje dan een query aan kunt maken en direct ziet welke als eerst betaald moet worden.
zie er geen nadelen in
 
Het nadeel is dat je een gegeven extra op slaat dat geen relatie heeft met de factuurdatum. Je kunt dus onafhankelijk van elkaar betaaldatum of uiterstedatum veranderen. Met een betaaltermijn heb je die relatie wel. Verandert de factuurdatum, dan verandert automatisch de uiterste betaaldatum. Je kunt op deze manier ook altijd een overzicht zien van de eerstvolgende te ontvangen facturen, want zoals gezegd: de uiterste betaaldatum is heel simpel uit te rekenen.
In beginsel moet je een tabel zo opbouwen dat je geen gegevens opslaat die af te leiden zijn uit andere gegevens. Zo heb je in jouw voorbeeld bijvoorbeeld Product en Productnummer in tabel1. Maar Product is af te leiden uit Productnummer, dus je slaat geen Product op.
Ik denk (en steeds steviger...) dat je nog eens goed moet kijken naar je tabellen, en wat je er mee wilt doen...
 
ik heb geen product gegevens bij een product nummer.
en het maakt me niet uit of een prodcut ergens dubbel staat.
het is niet voor op een site of iets dergelijks.
mij gaat het niet zo om de omvang maar om de functionaliteit daarom beperk ik niet de meeste functies.
ik wil gewoon een systeem waar ik alle facturen in vul en dat ik ze snel kan vinden.
het hoeft niet geexporteert te worden of iets dergelijks gewoon functioneel en makkelijk voor anderen om mee te werken
 
Juist door velden dubbel te gebruiken maak je het systeem moeilijk en lastig te onderhouden.... Dat geldt zeker voor het veld Product, vanwege de eerder genoemde bezwaren. Nog niet genoemd: als een produktnaam of produktomschrijving verandert, zit je met het probleem dat je tabellen ook niet meer kloppen...
Wij proberen je te helpen om je db zo goed mogelijk op te zetten. Dat houdt ook in, dat je probeert de db zo onderhoudsvriendelijk mogelijk te maken, en dat heeft niks met websites te maken. Daarbij moet je zelf dus eerst nadenken over wat de db moet doen, wat je in wilt kunnen vullen en terugvinden, en daarna ga je het systeem zodanig bouwen dat je die wensen kunt uitvoeren. Ik heb het idee dat je niet goed hebt nagedacht over de opzet, en te snel resultaat wilt zien. Met als gevolg een verkeerd uitgangspunt. Het zou je namelijk wè uit moeten maken of je datumredundantie hebt of niet...
 
toch bedankt voor jullie hulp maar ik wil gewoon iets maken zoals ik het wil hebben en niet zoals iemand anders het wil hebben.
dus het is niet mogelijk om: als je 2 tabellen hebt in 1 iets in te vullen en het wordt in de ander ook erin gezet?
 
Eigenwijs zijn mag, geen problemen mee ;) Met opzet een db gaan maken waar je later mee in de problemen gaat komen: :( Maar tot zover moet je het zelf weten...
Niet lezen wat er wordt gezegd.... vind ik al een behoorlijk stuk minder :confused:.
Je vraag is min of meer al beantwoord: op je formulier een knop maken die de gegevens in twee tabellen opslaat, met twee toevoegqueries bijvoorbeeld.
 
de antwoorden heb ik wel gelezen.
maar er zat helaas niet bij wat ik wou weten.
hoe werkt dat met die knop dan?
ik heb al een formulier waar alle gegevens worden ingevoerd
 
Simpelste oplossing: maak een toevoegquery, en gebruik als invoer de velden op het formulier. Via de knop <Opbouwen> kun je de velden vullen, en bij <Toevoegen Aan> selecteer je het veld waarin je de waarden op wilt slaan.
 
laat maar ik bel wel iemand op als ik steeds geen antwoord op mijn vraag krijg maar een ander idee
 
aangepast

ok ik heb het naar jullie idee aangepast.
nu heb ik 2 tabellen
  • Facturen
  • Leveranciers

In facturen staat
  • Factuur nummer(autonummering)
  • Leveranciers nummer (die hetzelfde moet zijn aan het leveranciersnummer in de tabel leveranciers)
  • Leveranciers
  • Factuur bedrag(valuta)
  • datum verwachte betaling(datum)
  • Verval datum(datum)
  • Datum factuur(datum
  • Betaald (ja/nee)
in leveranciers staat
  • Leveranciers nummer (automatische nummering)
  • Verkorte naam (initialen)
  • Naam
  • Adres
  • Postcode
  • Woonplaats
  • land
  • Telefoon nummer
  • Fax
  • E-mail
  • Bank
  • Rekeningnummer
  • BIC
  • IBAN


hoe koppel ik nu het Leveranciers nummer in de tabel facturen aan die van de tabel leveranciers.
en welke moeten primaire sleutel zijn, ik heb nu leveranciersnummer als primaire sleutel en Factuurnummer
 

Bijlagen

  • test2.zip
    11,3 KB · Weergaven: 32
Laatst bewerkt:
Je blijft nogal onzeker over de betaaldatum.... bij elkaar 4 velden, waar je er aan twee ook genoeg hebt. En dan te bedenken dat je niet eens de Betaaldatum opslaat, dus je zou eigenlijk 5 velden nodig hebben!
Maar goed, als je graag datums invult, dan moet dat kunnen ;) Maar bedenk, dat een ingevulde [DatumBetaald] toch zou moeten betekenen dat een factuur betaald is, en een leeg veld [DatumBetaald] dat er nog niet betaald is. Dus een Ja/Nee veld [Betaald] is volslagen overbodig.... En als je wel een datum invult, maar niet op het selectievakje klikt, is de factuur dan betaald? Of omgekeerd: je klikt op het selectievakje, dus er staat een vinkje, is de factuur dan betaald, ook als er geen datum is ingevuld in de andere datumvelden? En weet je zonder veld [DatumBetaald] wel wanneer een factuur betaald is? Het jeukt bij mij echt aan alle kanten....

Om op de vraag terug te komen: in het scherm Relaties sleep je nu het veld LeverancierNummer uit de tabel Leveranciers naar het veld LeverancierNummer in de tabel Facturen. Zorg dat de optie <Referentiële Integratie afdwingen> geselecteerd is, en klik op OK. Je hebt nu een één-op-veel relatie gelegd tussen de twee tabellen.
In de tabel Leveranciers is het veld [LeverancierNummer] de primaire sleutel. Dit is dus een unieke waarde. Omdat elke leverancier meerdere facturen mag ontvangen, is het in Facturen geen sleutel. Vandaar dus de één-op-veel relatie. Je hoeft dus in de tabel Facturen geen veld [Leveranciers] te hebben, want ook dat is weer dubbelop. Uiteindelijk laat je de Leveranciersgegevens wel zien op je factuur en je formulier, maar je slaat ze dus nooit op in je tabel.

Op je Formulier maak je een keuzelijst met invoervak, waarin je uit de tabel Leveranciers de leverancierscode opzoekt. Deze waarde sla je op in de tabel Facturen. Met de Wizard is het maken van die keuzelijst een peuleschil...
 
Status
Niet open voor verdere reacties.
Steun Ons

Nieuwste berichten

Terug
Bovenaan Onderaan