multi-user met beveiligingen

[LaLiselotte]

Hallo iedereen!

Ik heb op mijn stage een opdracht omtrent Access gekregen. het is de bedoeling dat het huidige bestand waar mee gewerkt wordt van single-user naar multi-user gaat. op zich geen probleem, want er is een gedeelde schijf om op te slaan.

Maar nu is de vraag van mijn stagementor om ervoor te zorgen dat niet iedereen overal in kan. situatie: 8 verschillende afdelingen/ateliers, waar bestelbonnen voor lopen. om saldo's en dergelijke te bekijken, moeten de afdelingshoofden steeds naar admin hollen om het na te vragen. het is de bedoeling dat de ateliers allemaal toegang krijgen tot het bestand; MAAR ze mogen enkel hun eigen gegevens zien.

hoe begin ik hier aan?
zonder te moeten werken in VBA, mySQL of SharePoint.

Alvast bedankt!!!

 

[OctaFish]

Met welke Access versie wordt er gewerkt?

 

[LaLiselotte]

Met welke Access versie wordt er gewerkt?

Er wordt in Access 2007 gewerkt..

 

[OctaFish]

Dan zul je denk ik toch iets met VBA moeten gaan doen. In oudere versies kon je met Gebruikers en Gebruikersgroepen exact aangeven welke gebruiker wat mocht doen en zien, maar dat principe is door Microsof overboord gezet ten faveure van een beveiliging die die naam eigenlijk niet meer verdient...
Je kunt nog wel het e.e.a. zelf bouwen op basis van Logintabellen waarin je de users vastlegt en per user een rechtenschema meegeeft. Je formulieren baseer je dan de op queries waarin gefilterd wordt op recordsets die zijn gebaseerd op het rechtenschema. Klinkt als veel werk? Is het ook wel een beetje... Het voordeel van het zelf maken is wel dat je het volledig kunt toesnijden op de praktijksituatie. Het oude proces met een mdw bestand werkte ook niet erg intuïtief. Maar je hoefde er niet voor te programmeren, en dat zul je vrees ik toch moeten gaan doen.
Op deze Microsof site lees je wat meer informatie.

 

[LaLiselotte]

Dan zul je denk ik toch iets met VBA moeten gaan doen. In oudere versies kon je met Gebruikers en Gebruikersgroepen exact aangeven welke gebruiker wat mocht doen en zien, maar dat principe is door Microsof overboord gezet ten faveure van een beveiliging die die naam eigenlijk niet meer verdient...
Je kunt nog wel het e.e.a. zelf bouwen op basis van Logintabellen waarin je de users vastlegt en per user een rechtenschema meegeeft. Je formulieren baseer je dan de op queries waarin gefilterd wordt op recordsets die zijn gebaseerd op het rechtenschema. Klinkt als veel werk? Is het ook wel een beetje... Het voordeel van het zelf maken is wel dat je het volledig kunt toesnijden op de praktijksituatie. Het oude proces met een mdw bestand werkte ook niet erg intuïtief. Maar je hoefde er niet voor te programmeren, en dat zul je vrees ik toch moeten gaan doen.
Op deze Microsof site lees je wat meer informatie.

Ik was al aan het inlezen over VBA, maar daar snap ik echt helemaal niks van... ik doe ook geen informatica-studie, dus ligt dat compleet buiten mijn werkveld..

 

[OctaFish]

Database beveiliging is sowieso geen beginnersonderwerp, vind ik. Wat je in ieder geval kunt doen, is de db splitsen in een Frontend en een Backend database. De Backend bevat dan de tabellen, en de Frontend zet je uit bij de users. Deze bevat dan de qeuries en formulieren die de gebruikers mogen zien en gebruiken.

Door voor elke groep een aparte frontend te maken met eigen queries, kom je ook al een heel eind. Je zult dan nog wel moeten voorkomen dat gebruikers de verkeerde frontend openen, maar op een beveiligd netwerk moet dat geen probleem zijn. Meestal heb je toch wel per gebruiker een persoonlijke schijf, een afdelingsschijf en een gezamelijke schijf. De backend staat dan op de algemene schijf, en de frontend op de afdelingsschijf. Het werk zit 'm er dan in dat je voor elke groep een eigen frontend moet maken. Maar dat kun je ook nog wel enigszins automatiseren door in de backend een tabel met afdelingen op te nemen, en in de frontend in de queries te verwijzen naar die tabel. In de opstartprocedure van de db leg je dan vast via welke afdeling er wordt ingelogd, en de queries laten dan de overeenkomende records zien. Of zoiets... Daar hoeft op zich niet zoveel aan geprogrammeerd te worden, alleen dus het vaststellen van de afdelingscode.

 

[LaLiselotte]

Database beveiliging is sowieso geen beginnersonderwerp, vind ik. Wat je in ieder geval kunt doen, is de db splitsen in een Frontend en een Backend database. De Backend bevat dan de tabellen, en de Frontend zet je uit bij de users. Deze bevat dan de qeuries en formulieren die de gebruikers mogen zien en gebruiken.

Door voor elke groep een aparte frontend te maken met eigen queries, kom je ook al een heel eind. Je zult dan nog wel moeten voorkomen dat gebruikers de verkeerde frontend openen, maar op een beveiligd netwerk moet dat geen probleem zijn. Meestal heb je toch wel per gebruiker een persoonlijke schijf, een afdelingsschijf en een gezamelijke schijf. De backend staat dan op de algemene schijf, en de frontend op de afdelingsschijf. Het werk zit 'm er dan in dat je voor elke groep een eigen frontend moet maken. Maar dat kun je ook nog wel enigszins automatiseren door in de backend een tabel met afdelingen op te nemen, en in de frontend in de queries te verwijzen naar die tabel. In de opstartprocedure van de db leg je dan vast via welke afdeling er wordt ingelogd, en de queries laten dan de overeenkomende records zien. Of zoiets... Daar hoeft op zich niet zoveel aan geprogrammeerd te worden, alleen dus het vaststellen van de afdelingscode.

Klinkt als iets goed, voor een nog niet draaiend bestand... of zie ik dat verkeerd?
Hier werkt men al 2 jaar met dit bestand en er mag dus ook zeker niks verloren gaan.. het is dus ook een vrij delicate kwestie..
Momenteel is er het bestand en een side-bestand 'basistabellen'.. basistabellen is gelinkt aan het bestand..
Dus dit is al een soort van FE en BE, maar toch niet helemaal natuurlijk... en door de wijze waarop het is opgesteld op dit moment, lijkt het mij een echt geklungel om te splitsen in FE en BE... Het zou maar een puinhoopje worden, toch?

 

[OctaFish]

Dat valt wel mee; je kunt een bestaande db makkelijk (alles is relatief uiteraard...) omzetten naar een echte FE-BE situatie. De meest simpele manier is om twee kopieën te maken van de hoofddb. De eerste kopie noem je DBNaam_FE, en de ander DBNaam_BE. In de Frontend gooi je alle tabellen weg, ook de gekoppelde, en in de Backend alle formulieren en rapporten etc.

In de Frontend maak je dan vervolgens koppelingen naar alle tabellen in de Backend, en dan ben je eigenlijk al klaar. Je Frontend doet het nog steeds, en je Backend ook. De Backend kun je vervolgens beveiligen, zodat onbevoegden niet bij de gegevens kunnen en in de Frontend ga je dan de restricties op de queries bouwen. Als de db al goed werkt, dan hoef je aan de formulieren verder ook niet zoveel te doen, alleen dus de restricties inbouwen die je nodig hebt. En daarvoor heb je de tabel met usergegevens/afdelinggegevens nodig die je in de BE zet.

 

[LaLiselotte]

Dat valt wel mee; je kunt een bestaande db makkelijk (alles is relatief uiteraard...) omzetten naar een echte FE-BE situatie. De meest simpele manier is om twee kopieën te maken van de hoofddb. De eerste kopie noem je DBNaam_FE, en de ander DBNaam_BE. In de Frontend gooi je alle tabellen weg, ook de gekoppelde, en in de Backend alle formulieren en rapporten etc.

In de Frontend maak je dan vervolgens koppelingen naar alle tabellen in de Backend, en dan ben je eigenlijk al klaar. Je Frontend doet het nog steeds, en je Backend ook. De Backend kun je vervolgens beveiligen, zodat onbevoegden niet bij de gegevens kunnen en in de Frontend ga je dan de restricties op de queries bouwen. Als de db al goed werkt, dan hoef je aan de formulieren verder ook niet zoveel te doen, alleen dus de restricties inbouwen die je nodig hebt. En daarvoor heb je de tabel met usergegevens/afdelinggegevens nodig die je in de BE zet.

Heel erg bedankt!
Ik ga dit in de komende tijd proberen.. (momenteel is mijn stagementor nog in vakantie)