AuditTrail

Status
Niet open voor verdere reacties.
M

MatthiasPBelmans

Gebruiker
Lid geworden
13 aug 2020
Berichten
50
Hoi

Ik zou graag een audittrail opmaken in een aparte tabel.

Het formulier waar de data ingegeven wordt heeft tabbladen erin.

Ik heb al wat sites af gegoogled maar tot op heden geen succes met het bouwen van mijn audittrail

Ik zou graag dat elke create en edit wordt opgenomen, records deleten zouden ze in principe niet mogen.

Kan iemand hier mij met helpen?

Tx
 
Je kan voor de tabel een historiek tabel aanmaken en ofwel:
* via code in het formulier de gewijzigde/nieuwe waarden opslaan, samen met de datum waarop de wijziging werd doorgevoerd en wie de actie uitvoerde
* als de gegevens via meerdere formulieren kunnen aangepast worden kan je ook een trigger op de tabel zelf zetten die de wijzigingen opslaat in de historiek tabel (zie afbeelding)

Triggers.JPG
 
Maak eens een voorbeeldje, dan weten we ongeveer wat je wilt hebben. Ik gebruik regelmatig Audittrail tabellen, dus er is van alles mogelijk.
 
Je voorbeeld is een 'beetje' incompleet, want van (op twee na) elke keuzelijst ontbreekt de bijbehorende tabel. Dat gaf mij dan weer wél de gelegenheid om jou voor een hoop aankomende ellende te behoeden, want ik heb dus maar in je tabel alle keuzelijsten die op een tabel zijn gebaseerd omgezet naar een tekstveld. En daarbij dus de welgemeende waarschuwing: DOE DAT NOOIT!! Keuzelijsten horen thuis op formulieren, niet in tabellen. In een tabel (vind ik, anderen denken daar anders over) moet je te allen tijde de werkelijk opgeslagen waarde kunnen zien, en niet de waarde die je in de keuzelijst laat zien. Al was het maar omdat je in exports dan ineens hele andere resultaten te zien krijgt.... Leer jezelf dus af om keuzelijsten te maken in tabellen, tenzij op basis van Lijst met waarden, waar je er ook twee van hebt. En die heb ik uiteraard laten staan.

Dat gezegd hebbende: wat wil je precies wanneer registreren? Ik kan me voorstellen dat je wél wilt vastleggen dat iemand een nieuw record heeft toegevoegd of verwijderd, maar in die gevallen wil je denk ik niet alle oude/nieuwe values opslaan. Die zijn er dan namelijk niet. Althans: bij toevoegen is er geen oude waarde, en staan alle nieuwe waarden in de tabel, en bij verwijderen zijn alle waarden wég. In dat geval wil je wellicht wél het complete record opslaan, maar je kunt beter dichtspijkeren dat er niet verwijderd mag worden, omdat je database historie dan doorgaans gelijk corrupt is. Hooguit zul je willen vastleggen dat een verkeerd aangemaakt record, wat dus logischerwijze wél mag worden verwijderd, is verwijderd door een daartoe geautoriseerde persoon. Maar omdat het dan om een foutief record gaat, lijkt me de ingevoerde waarden dan minder interessant om te bewaren.

Dan hebben we het dus over de mutaties waarvan je oude en nieuwe waarden kan vastleggen. Is dat ongeveer het idee?
 
Hey OctaFish tx voor de tip van de keuzelijsten! Zo ver had ik nog niet nagedacht.

Het is de bedoeling dat de audittrail registreerd als er een nieuw record wordt aangemaakt.
Verwijderen van een record mag nooit, dit omdat alles moet getraceerd worden.

Zodra er een wijziging in een veld wordt gedaan bv datum veranderd of extra informatie ingevuld zou dit ook moeten geregistreerd zijn.
Als er in een veld geen wijziging is, moet dit dan weer niet geregistreerd zijn.

Ik hoop dat ik wat duidelijk ben :)
 
Dat is ongeveer wat ik zei, dus duidelijk genoeg :). Overigens zou ik dus wel degelijk de mogelijkheid open laten dat een db beheerder records kan verwijderen, als daar noodzaak voor is. Dat kan namelijk altijd wel een keer voorkomen. Dan wil je niet met records blijven zitten die de bedrijfsresultaten vertroebelen. Ik heb het dan over records die onmiddelijk na het aanmaken verwijderd worden, en die dus geen invloed hebben op andere bedrijfsaspecten, zoals doorlopende nummeringen etc. Als je bijvoorbeeld een handmatige nummering gebruikt voor facturen, dan mag een record van vorige week niet meer verwijderd worden, als er opvolgende facturen zijn aangemaakt. Dan zou de nummering namelijk niet meer kloppen. Maak je per ongeluk twee keer dezelfde factuur aan, dan is er weinig op tegen om de tweede direct te verwijderen. Dat heeft dan geen invloed op de verdere bedrijfsprocessen.
 
aah oke :) ja ik ben nog niet bezig met userrechten per gebruiker ofzo, daar heb ik al helemaal geen ervaring mee
 
Toch is het goed om daar nu al rekening mee te houden. Sterker nog: in mijn ogen is het van noodzakelijk belang dat je alles (of in ieder geval: zoveel mogelijk) van te voren bedenkt qua processsen, en daar bij het ontwerp dus rekening mee houdt. Te vaak zie ik dat mensen gelijk beginnen met bouwen, en tijdens het bouwen dan gaan bedenken wat er allemaal wel en niet moet kunnen met de db. Terwijl het andersom moet zijn: eerst de processen beschrijven en vastleggen, en die dan uitwerken in User stories zodat je kunt bepalen welke processen je wilt ondersteunen met de database. En als dát is goedgekeurd, gaan kijken hoe je dat gaat verwezenlijken.

Ik zal in ieder geval in je voorbeeldje de knop Save (waar nu een nutteloze macro onder hangt) vervangen door een code die de historie vult. Een knop Save is in een database zinloos, omdat je bij het bladeren/sluiten automatisch al het record opslaat. Of de vraag krijgt (bij sluiten) of je het record op wilt slaan.
 
aanvulling: de knop Save is bij het standaardgebruik van Access zinloos, en aangezien Access slechts een heel klein deel van de database toepassingen omvat (de meeste zijn web based) is een Save knop in de meeste cases wel degelijk nodig. Ook in access kan je met ongebonden data formulieren werken, en dan is een Save button ook nodig.
 
Laatst bewerkt:
NoellaG zei:
(de meeste zijn web based)
Klik om te vergroten...
Hoe kom je daar bij? Misschien bij jullie, maar echt niet overal. Sterker nog: ik heb maar één keer een webbased Access database gemaakt. Wellicht ben ik een prutser, dat zou natuurlijk kunnen. Ik ben het wél met je eens dat een Opslaan knop nodig is bij een niet-afhankelijk formulier, mits je dat in het gebruik aan een tabel koppelt. Maar dat is zeker geen standaard activiteit, en wordt door weinig Access gebruikers gedaan.
Mijn opmerking betrof (uiteraard) over het bijgeleverde voorbeeld, waar de knop wel degelijk overbodig is.
 
Ik denk een klein misverstand: ik heb het zeker niet over webbased Access applicaties, maar over web based applicaties (JAVA, .net, C#, HTML, noem maar op). Microsoft heeft vroeger wel een poging gedaan om webpages met access te maken, maar heeft dit zelf terug afgebouwd. In mijn ervaring als zelfstandig consultant bij meerdere bedrijven wordt Access niet echt meer gebruikt, hier en daar een kleine rogue app te buiten.
 
Laten we de antwoorden tot de feitelijke vraag beperken. Dit is niet de plek voor discussies.
 
ik weet dat de knop save weinig nut heeft, dit is echter voor mijn collega's die niet zo vertrouwd zijn met MS Access., De knop geeft hun een soort "garantie".
 
Beter is het ze 'op te voeden'. Schijnveiligheid aanbieden lijkt mij een nutteloze bezigheid. Het is aan jou om ervoor te zorgen dat die veiligheid er ook daadwerkelijk is. Als een gebruiker bijvoorbeeld een formulier sluit zonder dat het bewerkte record is bewaard, kun je de vraag laten stellen of het record bewaard moet worden of niet (met de voorkeur op Ja). De gebruiker heeft dan de keuze om dat wel of niet te doen. De keuze blijft dan bij de gebruiker. Wat ik wil zeggen is: biedt alleen knoppen en acties aan die daadwerkelijk wat doen voor een gebruiker. Dan snapt-ie des te sneller hoe het programma werkt, en wat de logica in het systeem is.
 
Je kan anders werken met een ongebonden formulier dat de gegevens pas wegschrijft op het moment dat de gebruiker de Save knop klikt.
Voordeel:
* men kan niet per ongeluk reeds bestaande gegevens overschrijven
* men werkt zoals men gewoon is
* je kan gegevens naar meerdere tabellen gelijk wegschrijven
* je haalt slechts die gegevens in het formulier die de gebruiker gezocht heeft in plaats van de complete recordset
Nadeel:
* je moet het zelf in VBA programmeren

maar als je vertrouwd bent met VBA is dit zeker een valabele oplossing.

Vriendelijke groeten
NG
 
Zal 'm vanavond posten :).
 
Hoi, heb je mijn vraag nog eens bekeken OctaFish? sorry dat ik er nog eens achter vraag :)
Maar ik loop wat vast met mn db anders :)
 
Nog weinig tijd voor gehad, maar ik zal deze week een opzetje maken!
 
Status
Niet open voor verdere reacties.
                    Steun ons                    

Nieuwste berichten

Terug
Bovenaan Onderaan