Begrijp de foutmelding niet

Status
Niet open voor verdere reacties.

JJZijlstra

Gebruiker
Lid geworden
26 nov 2013
Berichten
283
Beste lezer(s),

Wat is er toch mis met mijn gegevensbestand en waarom kan ik geen records meer toevoegen vanuit de forumulierweergave? Dan krijg ik een foutmelding te zien die ik niet begrijp.
(Enkele gegevens heb ik via de tabel toegevoegd).
Zelf heb ik het gevoel dat het op een of andere manier aan de relatie ligt. Voor zover ik nagaan heb ik geen dubbele records in het bestand.

Kan iemand mij helpen?
Voorbeeldbestand is toegevoegd.

Groet,
 

Bijlagen

  • Klantenbestand.zip
    1,9 MB · Weergaven: 33
@AccessGuru,

Het verbaast mij dat u geen foutmelding kreeg.
Zelf heb ik nog enkele keren geprobeerd een record toe te voegen en te voorzien van gegevens in het subformjulier.
Krijg dan de volgende melding te zien, zie bijgevoegde foto als screenshot.

Groet,
 

Bijlagen

  • ScreenHunter_199 Jul. 29 16.04.jpg
    ScreenHunter_199 Jul. 29 16.04.jpg
    60,7 KB · Weergaven: 30
In je voorbeeld zie ik maar één formulier (op de tabel Klanten) en die doet het prima. Wellicht niet het goede voorbeeld gepost?
 
De melding zou veroorzaakt kunnen worden doordat je in het subformulier de verkeerde velden gebruikt. Maar omdat ik dat niet heb, kan ik dat uiteraard niet controleren.
 
Nog wat: je hebt in je voorbeeldje wél een query gepost, die je wellicht op je formulier gebruikt. Die query bevat een fout. Dus dat zou een reden kunnen zijn dat je een foutmelding krijgt op het formulier. De fout is deze:
Code:
Totaalprijs: [AantalStuks*Stuksprijs]
Dat kan niet; als je een berekening maakt op twee velden, moet je die twee velden apart benoemen. Dus zo:
Code:
Totaalprijs: [AantalStuks]*[Stuksprijs]
Maar ook dán krijg je een foutmelding, want het veld [Stuksprijs] zit in twéé tabellen die allebei in je query zitten. Access kan die zelf nooit selecteren. Dus je moet de tabelnaam óók specificeren. En dan krijg je één van deze varianten:
Code:
Totaalprijs: [AantalStuks]*[Bestelling].[Stuksprijs]
Totaalprijs: [AantalStuks]*[Artikel].[Stuksprijs]

Daarbij heeft de eerste de voorkeur, mits je dat veld correct vult. Ik heb niet de indruk dat je dat nu doet, want in de tabel Artikel zijn de stuksprijzen wél gevuld, en in Bestelling níet. Dus daar gaat wat fout.

Daarnaast zit er nóg een ongemakkelijke, (zeg maar slechte) constructie in je database: je hebt wél een tabel Bestelling, maar géén tabel Bestelregels. Dus nu kun je per bestelling maar één artikel verkopen. Dat lijkt mij bepaald niet handig. Tenzij je een winkel runt waar dat altijd het geval is, bijvoorbeeld bij abonnementen. Maar dat kan ik hier niet bepalen. Dus kijk nog eens goed naar je voorbeeldje, en post een betere variant :).
 
@AccessGuru,

Heel veel dank voor uw uitgebreide informatie die ik ter harte heb genomen.
Inderdaad had ik in een vorig bestandje een fout gemaakt. Heb dit hoop ik nu aangepast.

Wel zie ik in mijn database dat het nog altijd fout gaat als ik gebruik wil maken van de numerieke velden, daar verschijnt namelijk het foutmeldingsbericht.
Is er misschien een conflict tussen Nummer en Autonummering? Lijkt me haast niet. Met tekstvelden heb ik geen problemen en verloopt alles goed.

Helaas ontdekte ik nu dat ik de query niet als subformulier heb opgenomen onder Klantgegevens maar dat is niet zo erg maar ik heb Klantenbestand (2).zip (73,4 KB) geüploaded als het bestand waar het om gaat, dus vergeet het Klantenbestand wat er boven staat.

want in de tabel Artikel zijn de stuksprijzen wél gevuld, en in Bestelling níet. Dus daar gaat wat fout.
Dat heb ik gezien en ook aangepast.

De berekende velden in de query heb ik nu aangepast zoals u me hebt geadviseerd.

je hebt wél een tabel Bestelling, maar géén tabel Bestelregels. Dus nu kun je per bestelling maar één artikel verkopen.
Wat bedoel je met "bestelregels"? Hoe kan ik dat het beste aanpakken?
Wel heb ik de velden in de query opgenomen die ik nodig heb. Er kan m.i. dan ook geen sprake zijn van "vekeerde velden" of verkeerde structuur.

Hoewel ik misschien heel lastig voor u ben, verzoek ik u vriendelijk dit nog eens na te gaan en hoop nu echt tot een goede oplossing te komen zodat ik verder kan.
Alvast bedankt voor alle moeite.


Groet,
 

Bijlagen

  • Klantenbestand.zip
    76,9 KB · Weergaven: 19
  • Klantenbestand (2).zip
    73,4 KB · Weergaven: 17
Laatst bewerkt:
Er kan m.i. dan ook geen sprake zijn van "vekeerde velden" of verkeerde structuur.
Dat is een opmerking die ik graag bij jou laat, er kan in mijn ogen altijd sprake zijn van een verkeerde structuur. En in jouw geval ben ik daar behoorlijk van overtuigd.

Zoals ik al zei: een bestelling zal doorgaans uit meerdere artikelen bestaan. Je wilt niet voor elk besteld artikel een aparte bestelling maken. (Toch?) Dat betekent dat je aan elke bestelling meerdere artikelen wilt kunnen toevoegen. En daarvoor heb je een aparte tabel nodig die middels een één-op-veel relatie is gekoppeld aan de tabel Bestellingen. Zelf noem ik zo’n tabel dan ‘BestelRegels’, maar elke naam is natuurlijk prima.

Ook deze opmerking:
Is er misschien een conflict tussen Nummer en Autonummering? Lijkt me haast niet.

vind ik een beetje kort door de bocht; numerieke velden die niet van hetzelfde gegevenstype zijn kun je niet aan elkaar koppelen. Dat zou bij jou dus echt wel het geval kunnen zijn.

ik kijk morgen wel even naar de db.
 
@AccessGuru,


Mijn dank voor uw antwoord.

Je hebt volkomen gelijk, het lijkt me beter om per bestelling meerdere artikelen te kunnen opnemen. Door mijn geringe ervaring keek ik niet verder dan alleen de velden en dacht dat dit de enige manier was.
Aansluitend hierop: Het ontbreekt me aan verdere kennis om een aparte tabel "Bestelregels" te maken. Hoe ziet dat er uit?

Op internet had ik eerder al gezocht naar voorbeeldenbestanden maar kon deze niet vinden. Er zijn voldoende filmpjes maar dat brengt tot nu toe ook geen duidelijkheid.
Hoop dat u mij voldoende wegwijs kunt/wilt maken in het opzetten van de nieuwe bestelstructuur zoals u aangeeft.

Ook ben ik benieuwd naar de oorzaak van mijn fout bij invoer van numerieke gegevens. Dit vind ik ook erg belangrijk.


Vriendelijke groet,
Toby
 
Laatst bewerkt:
Nog geen tijd gehad om naar de db te kijken, maar het maken van zo’n tabel mag niet moeilijk zijn, want hij onderscheidt zich in niets van andere tabellen.
1. Wat er in ieder geval in moet zitten: een veld Bestelnummer. Dit heb je nodig om de twee tabellen met een relatie te koppelen. (Eén-op-veel relatie met Bestelingen).
2. Uiteraard een veld Artikelnummer, Stuksprijs, Aantal, eventueel BTW tarief. Wellicht ook een kortingspercentage als je daar mee werkt.

Veel meer is niet nodig. In het venster Relaties leg je dan de één-op-veel relatie tussen Bestellingen en Bestelregels (met Referentiële Integriteit aangevinkt) en je kunt aan de slag. Op het formulier Bestellingen zet je dan ook het formulier Bestelregels (dat is dan een subformulier) en dan kun je aan de slag.
bij Het invoeren kun je dan per bestelling de artikelen toevoegen, en dankzij de koppeling zie je de juiste artikelen bij de juiste bestelling.

Zelf gebruik ik nog wat trucjes om automatisch de actuele prijs in de tabel Bestelregels in te voeren, maar dat is van later zorg. Kijk eerst maar eens of je dit aan de praat krijgt. Overigens zijn er zat voorbeelden te vinden in het Access forum, want deze constructie wordt heel vaak gebruikt.
 
Dankje voor je antwoord AccessGuru,

Ik zal jouw aanwijzingen grondig gaan bekijken en het lijkt me dat ik maar een nieuwe database ga opzetten waarin ik je adviezen ga verwerken.
Het gaat wel een aantal dagen duren, misschien wel een kleine week maar dan hoop ik ook iets te hebben wat je goedkeuring kan hebben.
Korte vraag: welke velden moet er in Bestelregels staan?
Er zullen nog altijd wel vraagjes overblijven maar dat is van latere zorg.

Kortom: Ik heb voorlopig huiswerk.

Nogmaals bedankt voor je antwoord en uiteraard zal ik de nieuwe database naar je gaan opsturen

Groet,
 
De fout komt doordat je bij de bestellingen het veld omschrijving geen combobox is maar een vrij in te vullen veld. Als je daar iets invult dan probeert de applicatie een nieuw artikelaan te maken met die omschrijving en aangezien je niet de ID meegeeft probeert deze een nieuw record aan te maken met de default waarde 0. In je tabel Artikel zie je dat dit één keer gelukt is. Maar de ID is de primaire sleutel van de tabel en deze moet uniek zijn, dus een tweede keer lukt dat niet meer en krijg je die foutmelding.

Bijgevoegd een voorbeeld met bestelregels.
 

Bijlagen

  • Klantenbestand.zip
    50,8 KB · Weergaven: 26
Ik vind het zó jammer als helpers ongevraagd complete oplossingen posten; wat leert een vraagsteller daarvan? Tip voor Toby: probeer eerst zelf een tabel Bestelregels te maken. Kom je daar niet uit: vraag dan verder, of bekijk het voorbeeld. Daar leer je het meeste van.
 
Korte vraag: welke velden moet er in Bestelregels staan?
Dat heb ik in bericht #10 al aangegeven. In essentie komt het hier op neer:

1. In Bestellingen zet je alle gegevens die betrekking hebben op de bestelling. Zoals bestel datum, klant, afleveradres (als dat afwijkt) etc.
2. In Bestelregels alle gegevens die betrekking hebben op de bestelde artikelen, zoals artikelnummer, prijs, aantal, korting, leverbaar (Ja/Nee veld) etc. Ik zou daar nooit een (berekend) veld voor het Totaalbedrag in zetten, want dat bereken je op het formulier of in een query.
 
Tegenspraak

Wat leert de Guru ons nu weer ? 1+1 = 0

Uit zijn eigen werk: Overigens zijn er zat voorbeelden te vinden in het Access forum, want deze constructie wordt heel vaak gebruikt.

Vervolgens: Ik vind het zó jammer als helpers ongevraagd complete oplossingen posten; wat leert een vraagsteller daarvan?


Mischien leert een vraagsteller door een complete oplossing te zien, wat sneller.

Groetjes
 
In ieder geval veel meningen en veel uitleg.

Tip voor Toby: probeer eerst zelf een tabel Bestelregels te maken. Kom je daar niet uit: vraag dan verder, of bekijk het voorbeeld. Daar leer je het meeste van.
Voor mezelf ga ik de tijd nemen om hiermee op een goede manier aan de slag te gaan. Goede tip van AccessGuru.
De voorbeelden ga ik grondig bekijken.

Daarna kom ik terug met een nieuwe door mij opgezette database. Als vervolgens blijkt dat er dingen (nog) niet goed gaan, dan zijn er reden om verder te vragen.

Groet,
 
Wat leert de Guru ons nu weer ? 1+1 = 0
Uit zijn eigen werk: Overigens zijn er zat voorbeelden te vinden in het Access forum, want deze constructie wordt heel vaak gebruikt.
Plettert je, plettertje, wat zit je toch onnozel in elkaar. En het is zo simpel: als iemand vraagt om een voorbeeld, dan krijgt hij/zij die uiteraard. Als iemand eerst zelf gaat zoeken naar voorbeelden: prima. Eigen initiatief is nooit verkeerd. TS bepaalt dus helemaal zelf.
verder probeer ik een TS de goede kant op te sturen, want dat leert in mijn optiek het best.
 
@NoellaG,

Dank voor het sturen van het voorbeeld. Ik ben bezig uw voorbeeld te besturen en te gebruiken maar loop tegen een foutmelding aan.

Situatie: ik heb net een nieuwe klant toegevoegd in formulier Klantgegevens.
Via Bestelling de datum van vandaag aangegeven.
Vervolgens een artikel ingevuld in Bestelregel.

Nu komt het cruciale:
Ik wilde hieronder nog een artikel toevoegen en dan verschijnt direct de foutmelding. Van deze foutmelding heb ik een foto ingestuurd.
Heb ik iets fout gedaan?

Wordt het artikel wel opgeslagen? Een lijstje met alle bestellingen zou welkom zijn.


Vriendelijke groet,
Toby
 

Bijlagen

  • ScreenHunter_135 Aug. 01 08.51.jpg
    ScreenHunter_135 Aug. 01 08.51.jpg
    59,8 KB · Weergaven: 30
Probeer mijn versie eens; ik heb ook wat lopen 'klooien'.
 

Bijlagen

  • Klantenbestand.zip
    64,7 KB · Weergaven: 29
Hallo,

voor je bestelregels kan toevoegen moet je eerst een bestelling aanmaken : je bestelregels zijn voor bestelling nummer 13 en als je in je tabel bestellingen gaat kijken zal je waarschijnlijk zien dat bestelling 13 niet bestaat.

Trouwens AccesGuru:
Probeer mijn versie eens; ik heb ook wat lopen 'klooien'.
,
waar blijft de regel:
Vervolgens: Ik vind het zó jammer als helpers ongevraagd complete oplossingen posten; wat leert een vraagsteller daarvan?.
:rolleyes::D
 
Status
Niet open voor verdere reacties.
Terug
Bovenaan Onderaan