Access en réseau et sécurité - SQL/NoSQL - Programmation
Marsh Posté le 28-04-2005 à 23:22:56
Oui, les clients peuvent accèder au fichier, les enregistrements ne se chevaucheront pas. Par contre, je ne sais pas quelle est la limite (je sais que ca marche avec deux clients...)
Marsh Posté le 28-04-2005 à 23:25:04
Déjà il faut bien-sûr séparer les données du reste. Donc sur le serveur, t'as un premier mdb avec uniquement les tables. Puis sur les postes clients, t'as les mdb avec les formulaire-états-etc., avec les tables liées. Pour la sécurité, il faut faire un groupe de travail (le fameux system.mdw), y mettre la liste des utilisateurs, les authorisations. Puis le mdw devra être placé sur le serveur aussi, et les postes clients joindront ce groupe de travail, et devront s'authentifier lors du lancement d'access
Marsh Posté le 29-04-2005 à 08:43:32
Bonjour
Merci pour vos réponses.
L’utilisation du fichier mdw me paraît compliquer, et si j’ajoutais des tables telle que utilsateur, groupe d'utilisateurs ... au niveau de la BD et créer un formulaire d'authentification (tout un module de gestion des utilisateurs) comment alors protéger le fichier .mdb se trouvant sur le serveur pour qu’il ne soit ni supprimer, ni modifier par les utilisateurs des postes clients..
Marsh Posté le 29-04-2005 à 09:03:20
Non, c'est 100 fois plus simple que de te taper ça à la main Et 100 fois plus sécurisé aussi
Marsh Posté le 29-04-2005 à 09:10:35
monia2 a écrit : Bonjour |
Salut,
Je ne sais pas vraiment ce qui est le plus simple entre la gestion des sécurités intégrées à Access ou une gestion des sécurités écrites par toi de A à Z Tout dépend aussi du temps que tu as devant toi pour coder tout ça.
Sinon, par rapport à la sécurité de tes fichiers mdb... Pour moi le problème c'est que si tu mets des droits au niveau du serveur empêchant les utilisateurs de modifier le fichier mdb, je ne pense pas qu'ils auront l'autorisation d'ajouter des records depuis ton appli... Mais c'est à tester. Par contre, tu peux tout à fait les empêcher de le supprimer (c'est déjà ça).
Moi quand je me trouve dans un cas comme ça, j'utilise un share réseau et sur les postes clients, je crée un icône sur le bureau (ou dans le menu démarrer) qui accède à l'appli avec un chemin UNC. De cette manière, les utilisateurs ne voient pas le share directement dans leur "poste de travail" et ils doivent un peu "bidouiller" pour y aller. Tu limites donc pas mal les restes.
Et puis, rien ne remplacera jamais un bon système de sauvegarde pour parer aux utilisateurs pas futés qui ont le "delete" facile... Regarde aussi du côté des softs style "Undelete" qui remplace la poubelle de Windows par un système proche de ce que faisait (en standard) Novell il y a déjà plus de 10 ans. Mais là n'est pas le débat
Marsh Posté le 29-04-2005 à 09:16:21
Suffit genre un serveur sous windows, et avec les authorisations NTFS, le problème ne se pose pas... Droit en modification, mais pas en suppression.
Sinon, avec la sécurité Access, faut aller lire 2-3 trucs sur internet, rien que pour le coup du compte Administrateur à virer du groupe Admin, et à en créer un autre sous un autre nom Tout ça ne s'improvise pas comme ça
Marsh Posté le 29-04-2005 à 09:18:44
bonjour fa
je n'ai pas compris
utiliser un share réseau et sur les postes clients, je crée un icône sur le bureau (ou dans le menu démarrer) qui accède à l'appli avec un chemin UNC.
qu'est ce qu'un chemin UNC?
Marsh Posté le 29-04-2005 à 11:30:19
UNC = Universal Naming Convention
C'est à dire que plutôt que de mapper un lecteur réseau, tu accèdes à ta ressource en faisant:
\\Nom_Serveur\Nom_Partage\Repertoire\Fichier.ext
Marsh Posté le 04-05-2005 à 17:22:37
Bonsoir,
que pensez-vous de cette solution:
Je pense installer sql server sur le serveur, créer une base access (à mettre sur les postes clients) en y attachant les tables à travers ODBC (ainsi je limite la possiblité de la suppression de la base), puis renommez au niveau de la base access les tables en USysNom, cacher les tables systémes et enfin protéger la base access éventuellement avec un mot de passe.
Je développerais l'application peut être avec VB6 au lieu d'access.
merci pour votre réponse
Marsh Posté le 05-05-2005 à 12:09:02
Pourquoi attacher les tables via ODBC ? Access gère lui-même la liaison de tables. Sauf si évidemment tu veux faire ça sous VB6
Marsh Posté le 17-05-2005 à 15:10:06
Bonjour,
J'ai un petit souci avec mes utilisateurs Access. Lorsqu'ils veulent lier ou publiposter un document word, il marque : "L'ouverture de ce document exécutera la commande SQL suivante :
SELECT * FROM v:\dossier\sous-dossier\document.doc
Des données provenant de votre base de données seront insérées dans le document. Voulez-vous continuer ?"
Jusque là tout va bien puis, il m'affiche :
"docs.doc est un document principal de fusion. Impossible de trouver sa source de données, v:\dossier\...\document.doc."
info complémentaire :
v: est un lecteur mappé ou se trouve les documents partagés de tout les utilisateurs (tout le monde à tous les droits sur le lecteur)
Le truc est que l'on peut se dire que la base n'existe pas mais elle existe bien. Une autre solution me permet de lier ce document mais en passant par le chemin UNC (\\serveur\doc_partage\dossier\sous-dossier\document.doc). Pour moi ca va, j'y arrive mais mes utilisateurs ca leur fait un peu trop a retenir et en plus j'ai pas trop envie qu'ils viennent fouiller dans l'aborescence des dossiers partagés du serveur car ils sont capables de me mettre un bordel monstre.
La question est :
Peut-on faire une requête SQL sur des lecteurs réseaux (ou mappés) ?
Merci d'avance pour vos réponses et/ou vos recherches
GTH29
Marsh Posté le 06-06-2005 à 10:23:49
creer un lecteur virtuel avec ta base sur chaque poste.
Z:\mabase.mdb
Marsh Posté le 28-04-2005 à 22:26:32
Bonsoir
J’envisage de développer une application avec Access (base et application), en réseau avec 5 postes maximum (un poste serveur et 4 postes clients), j’ai quelques questions :
Si on met le fichier mdb au niveau du poste serveur, les autres clients peuvent ils y accéder simultanément sans problème ? sinon comment créer des images de ce fichier au niveau des postes clients ?
Et la sécurité, comment est-elle géré ?
Merci pour votre réponse