ACCES VBA veld in tabel aanpassen

  • Onderwerp starter Onderwerp starter fde
  • Startdatum Startdatum
Status
Niet open voor verdere reacties.

fde

Gebruiker
Lid geworden
31 aug 2017
Berichten
110
Ik heb verschillende forms om aanpassingen te doen van gegevens van klanten (o.a. sector, adres, betalingsvoorwaarden, enz.....).
Om dit via een geijkte weg te doen zijn alle velden niet via de recordbron verbonden maar worden weergegeven via een DLookUp, omwille van willekeurige aanpassingen te vermijden.

Het probleem is dat als er een aanpassing dient te gebeuren: bv Me.txtBedrijfSector.Value = Me.cboBedrijfSectorNieuw.Value deze niet aanvaard wordt.
Dus m.a.w. zou deze aanpassing rechtstreeks in de tabel te worden weggeschreven. bv: tabel: tbl_bedrijf veld: SECTOR_BEDRIJF.

Kan iemand me hiermee helpen aub.
 
Heb je het niet moeilijker gemaakt dan nodig? Aanpassingen van de gegevens van een cliënt doe je toch gewoon via een formulier dat zijn gegevens haalt uit een tabel, query, etc.... zonder al die Dlookup's?
Dan zijn de aanpassingen aan je DB ook makkelijker te doen.
 
De ervaring heeft me geleerd dat mensen de gemakkelijkste weg steeds kiezen. M.a.w. copy/paste is snel uitgevoerd maar kan de bedoeling niet zijn.
Het is omwille van de registratie van de aanpassingen dat wij voor deze werkwijze geopteerd hebben.
 
Ik ben het met Johan eens, en snap je werkwijze ook niet. Sowieso is werken met DLOOKUP een waardeloze manier van werken, omdat je een waanzinnig slome oplossing hebt gekozen; Dfuncties zijn hier totaal niet voor bedoeld. Wat is er op tegen om je formulier aan de bron (=tabel) te hangen, en daar de mutaties op te doen?

Mijn ervaring is overigens niet dat mensen per definitie de makkelijkste weg kiezen, maar de beste weg. En jij, als ontwerper van de db, levert die beste weg. Pas als de db niet goed gebouwd is, en je mensen de gelegenheid geeft om daar omheen te wieberen, heb je een probleem.
 
Als ik het goed begrijp uit je onderstreepte gedeelte hierboven registreer je dus ook de mutatiebewegingen van de gegevens (of wil je dat ook doen) en wordt er dus weggeschreven naar een aparte tabel wat/wie/wanneer er iemand data veranderd heeft? Dat is een ander gegeven en veranderd mijns inziens niets aan mijn eerste stelling dat je best een tabel of query, etc.... onder een formulier hangt. Maar ik durf ook wel eens met tempvars of een Dlookup andere informatie in een formulier brengen als "losse" extra informatie voor de gebruiker.
 
Precies; mutaties sla je op in een tabel, en die hang je onder een formulier. Als je de brongegevens van de mutaties ook wilt bekijken, en je pikt die op middels een keuzelijst, dan is het nog weer vele malen makkelijker om die gegevens uit de keuzelijsten terug te lezen.
Of desnoods middels een query waarin je alle velden zet die je op je formulier wilt zien, en die dan ook nog eens muteerbaar zijn (als je dat wilt) of als basis kunnen dienen voor de mutatiehistorie. Echt, er zijn zoveel betere oplossingen dan wat je nu gebruikt!
 
Inderdaad elke wijziging wordt inderdaad geregisteerd maar ook communicatie naar personen wordt eveneens geregistreerd.
Dit voor alle hoofdtabellen. Klanten & leveranciers = tbl-bedrijf, contactpersonen = tbl_contact, sollicitanten (lees kandidaten) = tbl_sollicitant, uitvoerders = tbl_uitvoerders, uitvoerders loonopvolging = tbl_uitvoerder_loon en uitvoerder werkuur opvolging = tbl_uitvoerder_uurregistratie.
Alle wijzigingen wijzigingen mogen voor mij in principe rechtstreeks doorgevoerd worden, doch het management wil dit niet zomaar.
Dus elke wijziging of communicatie in welke vorm dan ook wordt geregistreerd in de tbl_bewegingen. Kwestie om oude gegevens steeds te kunnen opvragen indien nodig.
Als alle txt-velden op een form rechtstreeks aan de recordbron (qry en/of tbl) worden gelinkt kan m'n direct een wijzigingen doorvoeren in het desbetreffende txt-veld.
Dus de knop wijzigen heeft dan geen zin. Tenzij dit op een andere manier kan , graag zelfs me dit te laten weten.
(alle velden via de form_load op disabled zetten heb ik ook geprobeerd, doch enerzijds krijg je een grijze layout en het afvink-veldje is snel gekend).
Vandaar mijn vraag om de vba-code om rechtstreeks weg te schrijven naar een veld in een tabel.
 
Laatst bewerkt:
Alle wijzigingen wijzigingen mogen voor mij in principe rechtstreeks doorgevoerd worden, doch het management wil dit niet zomaar.
Tenzij ‘het management’ uit ervaren database bouwers bestaat, zou ik me daar niet zoveel van aantrekken. Wel uiteraard uitleggen waarom je iets bouwt, en vooral (daar is management dan wel weer goed voor) met ze afspreken wat ze nu precies willen hebben. Mij lijkt dat er bepaald niet goed is nagedacht over de functie van de database. Ben benieuwd naar het antwoord op de vraag of er een goed Functioneel Ontwerp is gemaakt :).

Laten we eens naar je eerste zin kijken, die lijkt me wel belangrijk. Je herhaalt hem later nog een keer: “Dus elke wijziging of communicatie in welke vorm dan ook wordt geregistreerd in de tbl_bewegingen. Kwestie om oude gegevens steeds te kunnen opvragen indien nodig.”
Dus: je krijgt allerlei mutatie(verzoeken) binnen, die niet allemaal goedgekeurd en doorgevoerd hoeven te worden, maar wel als zodanig geregistreerd. Ook de contactmomenten met de personen die de mutatie aanbrengen worden vastgelegd in die tabel. Dat roept gelijk weer een paar vragen op:
1. Waarom mag de persoon die de gegevens invoert, die niet doorvoeren in de tabellen?
2. Wie bepaalt dan wel welke gegevens worden gemuteerd?
3. Op welk moment wordt besloten om een mutatie alsnog door te voeren?
4. Is de persoon die de mutatie doorvoert een andere dan degene die de mutatie invoert?
5. Gebruik je de tabel tbl_bewegingen om oude gegevens terug te zetten?

Ik heb wel eens een database gemaakt i.v.m. een reorganisatie waarbij een groep mensen de bestaande persoonsgegevens moesten omzetten naar de nieuwe situatie, maar waarbij het ook mogelijk moest zijn om gegevens terug te zetten. En dat alles moest gelogd worden op datum/tijd en de medewerker die de mutatie gedaan had.

Ik heb daarvoor een formulier gemaakt waarin je links de oude velden van de tabel zag, en rechts lege tekstvelden die gelinkt waren aan de velden aan de linkerkant. Met een knop werden de mutaties dan doorgevoerd in de betreffende tabel, en de mutaties werden opgeslagen in de mutatietabel. Die mutaties waren gelinkt aan de personen, en op het hoofdformulier kun je dan in een subformulier per persoon zien welke mutaties er waren geweest. En met een klik op een mutatierecord kon je die mutatie weer terugzetten in de hoofdtabel.

Zo’n constructie zou voor jou ook prima werken denk ik. Je leest dan alle mutaties in de tabel tbl_bewegingen in, zonder dat ze worden doorgevoerd in de betreffende tabel. Dat gebeurt later door de persoon die wél bevoegd is om de mutaties door te voeren.
 
Mijn initiële vraag was bedoeld om ingegeven data die juist staat niet zomaar willekeurig te laten aanpassen door andere medewerkers omdat ze daar zin in hebben.
Een database is één ding, de gegevevens die erin steken en deze bij houden ; daar kruipt veel werk in. Maar is essentieel voor onze business.
Daar wij enkel diensten uitvoeren, dus werken met gegevens van bedrijven en personen worden we wel verplicht te werken volgens nieuwste GDPR-wetgeving.
Uiteindelijk dient de tbl_bewegingen enkel voor registratie en indien nodig voor als het gevraagd wordt een GDPR-uitdraai te maken.
Anderszijds hebben we in het verleden personen terug kunnen contacteren via oude gegevens omdat wijzigingen van o.a. email-adres en gsm-nummer veelal gebeuren maar wel worden bijgehouden.

Maar dit alles staat los van m'n eerste vraag.
Het probleem is dat als er een aanpassing dient te gebeuren: bv Me.txtBedrijfSector.Value = Me.cboBedrijfSectorNieuw.Value deze niet aanvaard wordt.
Dus m.a.w. zou deze aanpassing rechtstreeks in de tabel te worden weggeschreven. bv: tabel: tbl_bedrijf veld: SECTOR_BEDRIJF.
 
Mooie link; beschrijft exact wat ik een aantal jaren geleden al gemaakt heb en wat ik in mijn vorige bericht al beschreef.
Wat betreft TS: van dit soort zinnen
Mijn initiële vraag was bedoeld om ingegeven data die juist staat niet zomaar willekeurig te laten aanpassen door andere medewerkers omdat ze daar zin in hebben.
Lopen de rillingen mij harder over de rug dan bij de engste griezelfilm. Hoe kom je erbij dat andere medewerkers willekeurig gegevens gaan lopen muteren als ze daar zin in hebben? Wat is dat voor idioot bedrijf?
Ongewenste mutaties zijn perfect af te schermen met de juiste rechtenstructuur en beveiliging op je formulier. Daarnaast lijkt het mij dat je met die mensen eens een hartig woordje moet spreken...
 
Status
Niet open voor verdere reacties.
Terug
Bovenaan Onderaan