Ik heb een vreemd probleem. Als ik een tekstvakje op mijn formulier zet en deze verwijs naar een besturings elementbron, dan kan ik deze niet bewerken zodat het besturingselementbron aangepast wordt. Ik heb de eigenschappen van de tekstvakjes vergeleken met een ander formulier waar dat wel werkt, en zie geen verschil. Waarschijnlijk zit het probleem op het formulier, maar ook daar zie ik geen verschillen bij eigenschappen. Heeft iemand dit ook mee gemaakt?? en weet die de oplossing? recordbron van formulier is een query
tekstvakje bewerken
- Onderwerp starter Zurrik
- Startdatum
- Status
Goede morgen. Mijn formulier werkt met de volgende query:
SELECT ORDER.OrderID, ORDER.OrganisatieID, ORDER.Ordernummer, ORDER.Referentie, ORDER.Orderdatum, ORDER.Leverdatum, ORGANISATIE.Naam, ORGANISATIE.DebiteurenNummer, ADRES.Adres, ADRES.Postcode, ADRES.Woonplaats, LAND.Land, FACTUUR.Factuurnummer, FACTUUR.FactuurDatum
FROM (ORGANISATIE INNER JOIN (LAND INNER JOIN (ADRES INNER JOIN ADRES2ORGANISATIE ON ADRES.AdresID = ADRES2ORGANISATIE.AdresID) ON LAND.LandID = ADRES.LandID) ON ORGANISATIE.OrganisatieID = ADRES2ORGANISATIE.OrganisatieID) INNER JOIN ([ORDER] INNER JOIN FACTUUR ON ORDER.OrderID = FACTUUR.OrderID) ON ORGANISATIE.OrganisatieID = ORDER.OrganisatieID;
Maar ik heb totaal geen idee waar het probleem ligt. Dus ik weet ook niet welke informatie ik moet geven. Ik wil de orderdatum en de leverdatum kunnen veranderen. Daarnaast wil ik produkten kunnen toevoegen via een subformulier. Dat staat er al in.
SELECT ORDER.OrderID, ORDER.OrganisatieID, ORDER.Ordernummer, ORDER.Referentie, ORDER.Orderdatum, ORDER.Leverdatum, ORGANISATIE.Naam, ORGANISATIE.DebiteurenNummer, ADRES.Adres, ADRES.Postcode, ADRES.Woonplaats, LAND.Land, FACTUUR.Factuurnummer, FACTUUR.FactuurDatum
FROM (ORGANISATIE INNER JOIN (LAND INNER JOIN (ADRES INNER JOIN ADRES2ORGANISATIE ON ADRES.AdresID = ADRES2ORGANISATIE.AdresID) ON LAND.LandID = ADRES.LandID) ON ORGANISATIE.OrganisatieID = ADRES2ORGANISATIE.OrganisatieID) INNER JOIN ([ORDER] INNER JOIN FACTUUR ON ORDER.OrderID = FACTUUR.OrderID) ON ORGANISATIE.OrganisatieID = ORDER.OrganisatieID;
Maar ik heb totaal geen idee waar het probleem ligt. Dus ik weet ook niet welke informatie ik moet geven. Ik wil de orderdatum en de leverdatum kunnen veranderen. Daarnaast wil ik produkten kunnen toevoegen via een subformulier. Dat staat er al in.
Je query is dusdanig complex dat access niet meer het unieke record kan aanwijzen in de tabellen waar de update op moet plaats vinden.
Dat betekent dat de query niet meer updateable is (mooi word is dat). Je moet de UniqueTable property gaan gebruiken om dat toch mogelijk te maken.
Laat de term UniqueTable property maar eens vallen in de help van VBA editor en je krijgt hier meer informatie over.
Een andere mogelijkheid is om met unbound forms te gaan werken en de afhandeling richting database met behulp van code doen (mijn favoriet), maar dat is wel een heel andere manier van werken.
Dat betekent dat de query niet meer updateable is (mooi word is dat). Je moet de UniqueTable property gaan gebruiken om dat toch mogelijk te maken.
Laat de term UniqueTable property maar eens vallen in de help van VBA editor en je krijgt hier meer informatie over.
Een andere mogelijkheid is om met unbound forms te gaan werken en de afhandeling richting database met behulp van code doen (mijn favoriet), maar dat is wel een heel andere manier van werken.
Zou ik dan helemaal opnieuw moeten beginnen? Een andere manier van werken zou ik niet erg vinden, maar ik wil eigenlijk wel de beste manier leren. Welke raad je dan aan?
Ik heb wat rondgezocht op het internet. Met Unbound Forms moet ik toch ieder tekstvakje wat ik wil vullen zelf aangeven in VBA of niet. Bijvoorbeeld dmv een SQL-querie. Gaat dit sneller??
Ik heb wat rondgezocht op het internet. Met Unbound Forms moet ik toch ieder tekstvakje wat ik wil vullen zelf aangeven in VBA of niet. Bijvoorbeeld dmv een SQL-querie. Gaat dit sneller??
Laatst bewerkt:
Wat het beste is, is vaak ook een stukje persoonlijke smaak. Ik probeer het mijn gebruikers altijd zo makkelijk mogelijk te maken. Dat betekent voor mij dat ik snel geneigd ben om met overzichtsschermen te werken, veel listboxes en dan knopjes om bewerkingen uit te voeren via detail schermen.
Ik heb daar ooit eens een voorbeeldje van gemaakt en kon dat zelfs nog terugvinden. Dat heb ik voor je bijgesloten. In het voorbeeldje zit ook het gebruik van single select listboxen en multi select listboxen (kun je meerdere items in een listbox selecteren en daar dan vervolgens bewerkingen op uitvoeren).
Kijk maar eens of dat voor jou ook bruikbaar is.
Ik heb daar ooit eens een voorbeeldje van gemaakt en kon dat zelfs nog terugvinden. Dat heb ik voor je bijgesloten. In het voorbeeldje zit ook het gebruik van single select listboxen en multi select listboxen (kun je meerdere items in een listbox selecteren en daar dan vervolgens bewerkingen op uitvoeren).
Kijk maar eens of dat voor jou ook bruikbaar is.
Ja, unbound forms betekent programmeren. Dat is wat meer werk. Voordeel is wel dat je precies kunt maken wat je wilt op de manier die je wilt.
De snelste manier is alles met de wizards van access doen. Dan krijg je veel rotzooi, het ziet er niet uit, en je loopt vrij snel tegen een aantal irritante beperkingen van access aan (dat begin je volgens mij inmiddels te ontdekken).
Uiteindelijk besluit je dan toch om het maar zelf te gaan programmeren.
Bound forms zijn handig voor detail schermen, de detail formulieren in mijn voorbeeld zijn ook bound forms. Die maak je even snel met de wizard, vervolgens pas je ze aan tot ze zijn wat je zelf wilt.
Overzichtsschermen zijn bij mij ALTIJD unbound. Kijk maar naar de code achter het overzichtsscherm van de veel-op-veel relaties in mijn voorbeeld. Die is niet echt moeilijk.
Subformulieren gebruik ik niet veel, ik doe meer met listboxes en detailschermen (dubbelklikken op een regel in een listbox geeft bijvoorbeeld een detailscherm). Ik gebruik wel subrapporten, maar ja, rapporten zijn natuurlijk weer een verhaal op zich......
De snelste manier is alles met de wizards van access doen. Dan krijg je veel rotzooi, het ziet er niet uit, en je loopt vrij snel tegen een aantal irritante beperkingen van access aan (dat begin je volgens mij inmiddels te ontdekken).
Uiteindelijk besluit je dan toch om het maar zelf te gaan programmeren.
Bound forms zijn handig voor detail schermen, de detail formulieren in mijn voorbeeld zijn ook bound forms. Die maak je even snel met de wizard, vervolgens pas je ze aan tot ze zijn wat je zelf wilt.
Overzichtsschermen zijn bij mij ALTIJD unbound. Kijk maar naar de code achter het overzichtsscherm van de veel-op-veel relaties in mijn voorbeeld. Die is niet echt moeilijk.
Subformulieren gebruik ik niet veel, ik doe meer met listboxes en detailschermen (dubbelklikken op een regel in een listbox geeft bijvoorbeeld een detailscherm). Ik gebruik wel subrapporten, maar ja, rapporten zijn natuurlijk weer een verhaal op zich......
Ik denk idd dat ik die probleempjes begin tegen te komen. Meer programmeren vind ik niet erg. Dat wil natuurlijk wel zeggen dat ik ook meer queries moet gaan maken, wat ik ook leuk vind. Ik bedoelde eigenlijk met de snelste manier, of het programma niet trager wordt omdat er veel meer code is.
Zoals ik het nu begrijp moet ik dus voor ieder tekstveldje in mijn overzichtformulier een opdracht mee geven.
vb: Me.txtveldje = select blabla. (weet ik zo niet uit mijn hoofd, maar heb ik voorbeelden van).
en dan dit voor ieder veld of list of wat ook op mijn overzichtsformulier.
* Een subformulier is toch puur om een moeilijke query te ontlopen??
Zoals ik het nu begrijp moet ik dus voor ieder tekstveldje in mijn overzichtformulier een opdracht mee geven.
vb: Me.txtveldje = select blabla. (weet ik zo niet uit mijn hoofd, maar heb ik voorbeelden van).
en dan dit voor ieder veld of list of wat ook op mijn overzichtsformulier.
* Een subformulier is toch puur om een moeilijke query te ontlopen??
Je moet niet voor ieder tekstveldje een selectstatement gaan maken.
Je vult je tekstveldjes bij het openen van je formulier. Bij het sluiten van je formulier werk je dan je database bij. Dat maakt zaken een stuk eenvoudiger.
Een subformulier is bedoeld om 1 op veel relaties te kunnen onderhouden. Dat kan ook op de manier in mijn voorbeeld.
Cursus en Cursist kun je natuurlijk vervangen door bijvoorbeeld Klant en Adres. Listbox klanten en een listbox adressen.
De listbox adressen is leeg zolang er geen klant geselecteerd is. Als er een klant geselecteerd is laat je de adressen van de klant in de listbox adres zien. En een listbox Orders voor de orders van de klant. etc.
Je vult je tekstveldjes bij het openen van je formulier. Bij het sluiten van je formulier werk je dan je database bij. Dat maakt zaken een stuk eenvoudiger.
Een subformulier is bedoeld om 1 op veel relaties te kunnen onderhouden. Dat kan ook op de manier in mijn voorbeeld.
Cursus en Cursist kun je natuurlijk vervangen door bijvoorbeeld Klant en Adres. Listbox klanten en een listbox adressen.
De listbox adressen is leeg zolang er geen klant geselecteerd is. Als er een klant geselecteerd is laat je de adressen van de klant in de listbox adres zien. En een listbox Orders voor de orders van de klant. etc.
Laatst bewerkt:
- Status
