Iff functie in gebeurtenis procedeure

Goedemiddag,

Ik heb een knop gemaakt in een formulier. Als ik deze knop indruk wordt onderstaande procedure uitgevoerd.


Tot zover werkt alles goed.

In het formulier staat in de voettekst een optelsom. Het resultaat van deze som mag zowel positief als negatief zijn, en staat in euro's.

nu wil ik graag dat als er € 0,00 staat en ik de knop indruk die de procedure uitvoert, dat de procedure niet wordt uitgevoerd en dat ik hooguit een popup krijg met een tekst, zoiets als er is geen bedrag ingevoerd. Is het bedrag groter dan 0 of kleiner dan 0 dat de procedure dan wel wordt uitgevoerd.

Graag uw hulp hierbij,

BVD
Jac

Nog even afgezien van het feit dat ik je code niet bepaald de meest handige vind (bijvoorbeeld het formulier Start sluiten en gelijk weer openen? Waar is dat goed voor?), is het behoorlijk simpel aan te passen, door eerst de waarde uit het tekstvak op te vragen, en op basis van die waarde (<>0) de procedures uit te voeren.

Klopt, Het is inderdaad niet de meest elegante oplossing. Ik heb hiervoor gekozen omdat als ik de startpagina sluit en weer open, ik mijn startveld heb ververst en op die manier mijn net ingevoerde data weer kan zien. Wat dat betreft zijn beide regels overbodig.

Heb je misschien een programma regel die ik in kan voeren zodat ik deze kan invoegen en daar weer van kan leren

alvast bedankt

Je gebruikt iig niet de IIF functie, maar het IF statement. Dus:

Overigens zijn de query's ook "verdacht". Het lijkt erop dat je gegevens opslaat. Als je ze opslaat kan je ze ook gebruiken om je uiteindelijke doel te bereiken zonder ze op te slaan.

xps351 zei:

Overigens zijn de query's ook "verdacht". Het lijkt erop dat je gegevens opslaat. Als je ze opslaat kan je ze ook gebruiken om je uiteindelijke doel te bereiken zonder ze op te slaan.

Klik om te vergroten...

Dat is een klein beetje onzin (mag het niet groter meer zeggen ). De eerste query is een aanmaakquery, de tweede een toevoegquery. Sowieso zou ik ze nooit op deze manier uitvoeren, maar afgezien daarvan: het kan best nodig/handig zijn om gegevens naar een tijdelijke tabel over te halen. Daarvoor kun je niet altijd een selectiequery gebruiken. Denk bijvoorbeeld aan koppelingen met Excel, en een gegevensbestand met daarin parameters. Dus er is niks mis met een aanmaakquery uitvoeren. De derde query lijkt dan weer wél een selectiequery, en daarvan kun je je afvragen waarom die geopend wordt. Maar omdat we dus niks van de uitgevoerde procedure weten, is het nogal voorbarig om de queries 'verdacht' te noemen.

Heel erg bedankt voor de hulp die ik heb gekregen. de code werkt perfect.

In 2015 ben ik begonnen met het bouwen van de database
simpel een tabel:
artikelen
debiteuren

Door deze te combineren met elkaar kreeg ik door een toevoeg queury het zo voor elkaar dat ik data kon verzamelen, een knopje erbij en ik had een factuur. echter als ik de prijs van een artikel had aangepast, werd dit op elke factuur aangepast. het is in de loop van de jaren zo een wirwar geworden van Querys en tabellen dat als ik er nu naar kijk ik het ook niet meer allemaal snap hoe ik een en ander voorelkaar heb gekregen. Spijt? ja, maar om overnieuw te beginnen en alle data die enigszins versnipperd in de tabellen staat kwijt te raken vind ik ook weer zonde.
Dus ja de diverse stappen die ik zet zullen veel makkelijker kunnen. de berekening die ik laat uitvoeren in de bron Query zijn over de top en te ingewikkeld. Het BTW gedeelte is waardeloos. Het is jammer dat ik de database niet kan delen ivm de privacy van mijn klanten, anders had ik graag laten zien hoe het niet moet.

Nogmaals bedankt voor jullie inbreng, begrip en steun.

Met groet,

Jac

jacw zei:

Echter als ik de prijs van een artikel had aangepast, werd dit op elke factuur aangepast.

Klik om te vergroten...

Dat klinkt als een database waar niet of nauwelijks over is nagedacht. Is bij database een hele slechte werkwijze .

In beginsel is het niet zo moeilijk: je hebt klanten en artikelen. Dat zijn sowieso twee tabellen. Klanten kopen iets, dus je hebt ook een tabel Bestellingen nodig. Doorgaans koopt een klant meerdere artikelen (het zou in ieder geval mogelijk moeten zijn in het systeem), dus je hebt óók een tabel Bestelregels. Dat kun je herhalen voor Facturen en Factuurregels. Tot zover nog wel te volgen, denk ik.

Jouw probleem met de prijzen wordt veroorzaakt doordat prijzen, in tegenstelling tot klanten en artikelen, flexibel kunnen zijn: een prijs moet je kunnen veranderen. In de Access cursus geef ik daarvoor een aantal oplossingen, die jij blijkbaar niet gelezen hebt . De makkelijkste oplossing is om in de tabel Bestelregels ook een veld Artikelprijs op te nemen. Bij het maken van een bestelling vul je dat met de actuele prijs, en als het record is opgeslagen verandert de waarde dan niet meer. Ook niet als je daarna de prijs in de tabel Artikelen aanpast. Een andere oplossing is om de prijshistorie van de artikelen bij te houden in een aparte tabel, er artikelID, mutatie datum en nieuwe prijs. Dan kun je met een query altijd de juiste prijs opzoeken bij de bestellingen. Is iets meer werk, maar geeft wat meer inzicht in de bedrijfsvoering doordat je historie hebt op de prijzen. Kan interessant zijn.

Ook al heb je nu een wirwar aan tabellen, queries en wat niet meer, ik zou toch gaan nadenken over opschonen (beter nog: een nieuwe db maken) waarbij je de bestaande data, als de structuur in orde is, best wel kan importeren. Dan heb je in ieder geval een systeem waarmee je weer probleemloos vooruit kan. Dat vooruitzicht zie ik in de huidige situatie niet .

jacw zei:

Het is jammer dat ik de database niet kan delen ivm de privacy van mijn klanten, anders had ik graag laten zien hoe het niet moet.

Klik om te vergroten...

We hoeven uiteraard niet de complete productie database te zien. Een db met een aantal dummy records is al voldoende. Je zou bijvoorbeeld een kopie kunnen maken van de huidige db, en dan in de relaties de optie Verwijderen aanzetten, zodat je, als je een klant verwijdert, ook de bijbehorende bestellingen etc. verwijdert.
vervolgens verwijder je alle klanten, op een stuk of 4-5 na die iets besteld hebben, en daarvan anonimiseer je dan de klantgegevens. Als het goed is, heb je dan een relatief kleine database met dummy records. Tabellen die niet nodig zijn voor het probleem kun je uiteraard sowieso verwijderen. Kijk maar even of je daar de tijd en energie voor hebt .

Bedankt voor je aanbod.

Hierbij een kijkje in de inhoud van mijn brein.
Hierbij de link

https://drive.google.com/file/d/1uGOJLdocbGmqr6lp049aSmxbuRG3V28S/view?usp=sharing
De gegevens van week maand en kwartaal rapport werken niet. door gebrek aan data vind het rapport lege velden en daardoor een foutmelding.
De sla ik altijd handmatig op en dan kies ik uit in en ex btw. vervolgens druk ik al dan niet af.
Een herinnering kan ik pas sturen als de factuur datum 30 dagen oud is.
Bij de aanmaning moet ik ook nog de datum van de herinnering invullen.

Om in het tabblad overzichten te komen voer ik een wachtwoord in. in dit geval 8481

Met groet,
een leek in VBA Acces

Jac

Zal er tussen de wedstrijden door naar kijken .

Als je maar niet gillend gek wordt. En dan bedoel ik niet de voetbal wedstrijden.

Ik heb 'even' naar je db gekeken, en kreeg het formulier in eerste instantie ook niet aan de praat. Was even zoeken waar hij was, want temidden van een enorme berg zichtbare tabellen en formulieren, waren de queries en formulieren waar je vraag over gaat allemaal verborgen. Is dat een speciale intelligentietest? . Ik heb jouw subformulier weggegooid, en opnieuw gemaakt, deze keer als doorlopend formulier met een juiste formule in de voettekst, en nu werkt het formulier prima. Tevens van het formulier Factuur weer een normaal formulier gemaakt, niet op Gegevensinvoer gezet. Zodat je weer kan zien wat er aan bestaande records in zit. Leek mij toch handiger.
Verder jaag je denk ik zo'n beetje iedereen het bos in door de naamgeving van je queris:

Met de eerste query verwacht ik (en ik denk dus iedereen) een Aanmaakquery. Bij de tweede verwacht ik een Toevoegquery. Dat laatste klopt, maar het eerste dus niet: dat is namelijk óók een Toevoegquery! Hoe verwarrend wil je het hebben? Bij een aanmaakquery (wat hier makkelijk had gekund) maak je een nieuwe tabel aan. Nu kun je de code twee keer uitvoeren, en dan voeg je dus dezelfde gegevens gewoon nog een keer toe. En dat lijkt mij toch niet de bedoeling...