Eviter plusieurs accés simultanés à un recordset.
Le
John
Aprés qu'un utilisateur ait saisi ses données dans un
formulaire, ces données sont enregistrées dans une table
via un recordset (rs) ouvert par une requète SQL.
En gros ca se présente comme ca :
rs.Edit
rs( truc ) = valeur
' etc
rs.Update
Tout cela marche trés bien avec un seul utilisateur, mais pas
quand plusieurs utilisateurs mettent à jour en même temps.
Dans ce cas, quelles sont les méthodes à utiliser pour
éviter deux (ou plus) accès simultanés à un recordset ?
formulaire, ces données sont enregistrées dans une table
via un recordset (rs) ouvert par une requète SQL.
En gros ca se présente comme ca :
rs.Edit
rs( truc ) = valeur
' etc
rs.Update
Tout cela marche trés bien avec un seul utilisateur, mais pas
quand plusieurs utilisateurs mettent à jour en même temps.
Dans ce cas, quelles sont les méthodes à utiliser pour
éviter deux (ou plus) accès simultanés à un recordset ?
Bonjour,
Première chose, il va falloir regarder dans les options d'Access, parce
que par défaut, une fois qu'une base est ouverte sur une machine, aucun e
autre ne peut y avoir accès, donc il faut regarder les propriétés
concernées par le verrouillage. Je n'ai pas l'intitulé exact en têt e,
désolé, mais une option permet l'accès concurrentiel depuis plusieu rs
postes. Mais peut-être as-tu déjà vu cela si tu as pu essayer les a ccès ?
Et puis il faut lire dans l'aide ce qui concerne le verrouillage des
enregistrements. Je te laisse découvrir la différence entre verrouill age
optimiste, pessimiste ... ça se passe dans les propriétés d'un jeu
d'enregistrements, qu'on précise au moment de l'ouvrir.
Il existe une notion de transaction qui doit aider la cohérence d'une
base, en empêchant qu'une table soit modifiée si une modification don née
n'a pas pu avoir lieu dans une autre table, mais hélas les essais que
j'ai eu l'occasion de faire de ça montraient que ça ne fonctionnait p as
dans Access. Cela étant, je les ai faits en version 97.
Donc il fallait monter une usine à gaz avec un champ auquel on commence
par donner une certaine valeur qui signifie pas touche, pareil dans
l'autre table, on fait les modifications des deux côtés, on enlève la
valeur pas touche, et puis voilà.
Ah oui tiens si tu as l'occasion d'essayer les transactions avec une
version plus récente ...
| John a écrit, le 12/09/2012 18:44 :
| quelles sont les méthodes à utiliser pour
| éviter deux (ou plus) accès simultanés à un recordset ?
Désolé c'est ma faute : dans la table j'avais une clé primaire
qui n'était pas en AUTONUMBER, et c'est ca qui merdait :
deux accés *simultanés* en écriture tentaient d'inscrire le
*même* nombre en tant que clé primaire, donc conflit.
J'ai mis la base sur une 1e machine A ( en réseau )
Depuis une 2e machine B j'ouvre cette base, et en
même temps depuis une 3e machine C j'ouvre cette base,
depuis ces deux machines B & C je fais des saisies sur
les 2 formulaires puis je valide *en même temps* et
je n'ai plus de problème de conflit d'enregistrements.
.
Il s'agit d'Access 2007 sous Win XP Pro sur un réseau local.
Le nombre d'utilisateurs simultanés pourra atteindre 20 personnes.
Note que l'extension du fichier Access est .ACCDB (et non pas .MDB)
mais je ne sais pas ce que cela implique ...
.
Oui, c'est ce que je voulais éviter.
Maintenant le problème est que si deux utilisateurs
éditent et modifient un enregistrement *déja existant*,
et qu'ils valident tous les deux en même temps,
celui qui aura validé en dernier va écraser les
saisies de celui qui aura validé en premier ...
Je suppose que c'est un problème courant et connu,
et qu'il existe une technique simple pour l'éviter ?
( sans se taper 300 pages de documentation )
Ah oui pendant les formations on discute le bout de gras là-dessus
pendant une demi-heure une heure et on a l'impression d'échanger des
banalités, mais ... finalement, ce n'est pas inutile.
Donc alors on commence par verrouiller la table, puis on lit l'ancienne
clef sur le dernier enregistrement pour calculer la clef d'un nouvel
enregistrement, et ensuite on peut créer l'enregistrement, y écrire c e
qu'on a saisi avant, enregistrer et libérer le verrouillage.
Bien entendu, si quelqu'un a déjà accès à la table avant on ne pe ut pas
verrouiller, donc il faut attendre pour créer l'enregistrement. Sauf si
c'est juste un accès en lecture, auquel cas on a pris l'accès sans
verrouillage.
A priori, c'est une opération qui doit beaucoup se baser sur le bon sen s
pratique, lequel bien entendu doit pouvoir s'appuyer sur la connaissance
de ce qu'on a à disposition comme instructions d'accès et de verrouil lage.
C'est pour ça que je ne me rends pas bien compte si j'ai dit tout ce
qu'il y a à dire, ni si j'ai insisté un peu lourdement sur un point p ar
rapport à ce qui était nécessaire.
Autant sur les manipulations utilisateur je suis assez à l'aise pour
animer un cours, autant sur les verrouillages, j'imagine qu'il faut
mettre sur pied des exercices pour voir comment les gens s'en sortent et
évaluer si ils ont bien assimilé ce qu'il y a à assimiler. ça se peut
que j'aie ça à faire bientôt, d'ailleurs.
Donc, euh ... dis-moi à quel point c'est clair.
Ah ben oui mais ... c'est un point important. D'ailleurs je me rappelle,
quand on m'a demandé de migrer ma base arrière vers Oracle pour qu'on
puisse accéder à plusieurs en même temps, ça n'a marché qu'une fois que
j'ai trouvé cette option. Le principe est d'ailleurs le même si la ba se
arrière est sous Access, c'est juste que mon client n'a pas essayé le
multi-poste avec une base arrière en Access.
C'est-à-dire que si on commence par verrouiller le champ, avant
d'autoriser la saisie, l'autre utilisateur ne pourra de toute manière
pas saisir autre chose, puisque l'enregistrement est verrouillé. Donc,
comme ça, c'est simple.
Après, on peut se dire que si on verrouille pendant tout le temps qu'on
va saisir les modifications sur l'enregistrement, il va rester
verrouillé un bon bout de temps, et ça risque de paraître longuet p our
l'autre utilisateur. Donc, là, on peut cogiter, tiens si je crée une
table avec les verrous, que je dis que cet enregistrement-là est en
cours de saisie, je peux laisser mon utilisateur le modifier, mais en le
prévenant que quelqu'un d'autre est en train de modifier le même
enregistrement ailleurs, donc il est en train de vivre dangereusement
... Peut-être d'ailleurs qu'on fractionnera l'information entre
plusieurs tables, en fonction de qui va fournir les informations.
Tu vois, ce que je dis là est déjà beaucoup moins simple, et d'aill eurs
beaucoup moins orthodoxe, aussi. C'est une recherche d'un compromis dans
le but d'un peu de souplesse. Mais ... si tu es hésitant, je te suggè re
de peut-être te cantonner à l'approche orthodoxe, verrouiller plutô t
trop que pas assez, et puis ... eh bien l'utilisateur attendra un peu.
On ne te recrutera peut-être pas dans une agence de voyages sur cette
base-là, mais si on est vingt, j'imagine qu'on ne va pas souvent essaye r
de travailler à plusieurs sur le même enregistrement ? Sinon eh bien il
faudra être patients :)
Tout d'abord, je veux que tu saches que j'apprécie ton aide.
( j'ai l'impression que
Pour commencer, je ne suis pas du tout 'database designer',
mais à mon job on a besoin d'une base pour certains trucs
( je ne peux pas entrer trop dans les détails )
et c'est à moi qu'a été confié l'étude et la réalisation.
Au début j'ai utilisé au maximum les fonctionnalités internes d'Access
( relations entre tables liées, clés primaires, automatismes, etc )
pour assurer la consistance, mais j'ai eu de mauvaises surprises.
( je ne prétends pas que le problème soit uniquement dû à Access,
c'est aussi bien dû à l'incomplètude de mes connaissances )
J'ai tout repris from crash, avec des formulaires dont les champs
ne sont pas liés à des tables : je me charge de lire les champs saisis
puis de les écrire dans les bons champs des bonnes tables.
( et de conserver l'intégrité des champs de tables contenant
des entiers servant d'index pour pointer vers d'autres tables )
Au final, pour te donner une idée de la facon dont c'est fait,
TOUT est géré par du code Visual Basic : c'est pour moi la
seule facon de maitriser tout ce qui se passe dans cette base.
( et quand quelque chose déconne je sais corriger le bug )
J'imagine que cette facon de procéder te semble hérétique ...
J'aurais largement préféré m'appuyer sur les fonctionnalités
d'Access car cela m'aurait évité de tout faire 'à la main'
et m'aurait fait gagner du temps, mais je bosse sur
d'autres projets ( qui eux, sont mon métier ) et je n'ai
pas le temps ( ni l'envie ) de devenir 'designer Access'.
Bref, j'ai quand même pu maintenant aboutir
à une base qui tient trés correctement la route,
même s'il me reste quelques trucs à optimiser.
C'est trés clair.
De mon côté, je ne tiens pas à tout apprendre de MS-Access
comme si je devais en faire mon métier ( j'ai déja un métier :o)
Heureusement cela fait 25 ans que je pratique la programmation
( microprocesseurs, microcontroleurs, PC, etc )
alors quand un système met à disposition un langage
( même un langage aussi merdique que Visual Basic ) au moins
j'ai des outils pour m'en sortir et aboutir à une base correcte.
C'est marrant que tu parles d'Oracle, parce-que dans les années
1998/2002 j'ai bossé là-dessus pour une boite de bio-informatique,
j'ai fait des interfaces réseau sous forme de programmes Windows
qui s'interfacaient à Oracle en PL/SQL ... j'écrivais mes logiciels sous
MS-Visual C++ en langage C ( ca au moins c'est un VRAI langage )
Et tout cela marchait nickel. Faut dire qu'Oracle, c'est pas Access ...
Disons que, tant que l'utilisateur est prévenu, c'est déja ca.
On peut même lui dire QUI est en train de modifier l'enregistrement,
ensuite c'est à lui de voir s'il veut contacter l'autre utilisateur ou pas.
Mais je vois un problème potentiel dans les flags de blocage :
si un utilisateur accède à un enregistrement pour le modifier,
on positionne les flags ( indiquant 'pas touche, c'est verouillé' )
mais imagine que l'utilisateur quitte Access 'sauvagement',
ou qu'il y ait une rupture réseau, ou que son PC plante :
dans la base les flags de verrouillage vont rester positionnés
et plus personne ne pourra accèder à l'enregistrement, non ?
( et il faudra appeler l'admin (moi) pour débloquer la bête ... )
Oui, un des problèmes potentiels qu'il me reste à résoudre est celui-ci :
Si deux utilisateurs accèdent au même enregistrement en même temps,
il faut que je mette en place un truc pour que seul celui qui accède
en premier puisse modifier les données, mais en plus que l'autre
utilisateur soit prévenu que l'enregistrement est en cours de modif
par un autre utilisateur, histoire de lui éviter de saisir des données
qui au final seront de toutes facons écrasées par les données de l'autre.
Dans ma base j'ai créé une table avec les noms des utilisateurs
autorisés, les niveaux des droits utilisateurs, les adresses email, etc.
Quand un utilisateur ouvre l'interface ( formulaire ) Access,
je récupère le login Windows de l'utilisateur et le recherche
dans la table pour y lire les informations le concernant.
( si l'utilisateur n'est pas dans la table, j'affiche un message
genre ' Access denied ' puis je ferme la base et quitte Access )
Sinon j'autorise ou bloque des fonctionnalités suivant les droits attribués.
C'est déja une première barrière pour éviter les embrouilles.
J'ai aussi implémenté une table de log où j'enregistre les évènements
( login utilisateur, date/time, action réalisée, etc ) comme ca s'il y a
une couille je pense pouvoir remonter l'historique pour débugger.
J'ai aussi écrit une fonction VBA pour envoyer automatiquement des emails
aux utilisateurs en fonctions des actions impliquées par leur action sur la
base.
Aujourd'hui cette base se tient bien (je n'ai pas à en rougir) mais
comme je te l'ai dit, il y a encore des trucs que je voudrais fignoler.
Par exemple, je ne comprends pas trop ce qui se passe réélement
lorsqu'un utilisateur, depuis sa machine 'X' , ouvre la base ACCDB
qui est physiquement sur une autre machine 'Y' ( via le réseau )
Est-ce que Access ouvre sur la machine locale 'X' de l'utilisateur
une copie de la base, ou est-ce que Access se contente
d'établir une connection avec la base qui est sur la machine 'Y' ?
Une conséquence de cette question est que dans le code VBA,
1 - Soit toutes les variables ( integer, chaines, etc )
sont uniquement locales sur la machine 'X'
( donc propres à chaque utilisateur connecté )
2 - Soit elles sont les mêmes pour tous les utilisateurs.
Evidemment ca fait une sacrée différence.
Je ne sais pas si mes questions sont bien claires ?
Tant mieux :)
C'est vrai qu'il y a des gens qui sont partis ...
J'ai mis trois ans à maîtriser Access en m'accrochant, et j'avais dé jà
des notions au départ. Au bout de dix ans, je jette à peine un coup
d'oeil à l'aide de temps à autre.
Un point sur lequel on insiste trop rarement : c'est une grave erreur de
confier le développement d'une base Access à quelqu'un qui n'est pas
solide sur une méthode d'analyse, comme par exemple Merise. C'est comme
ça qu'on voit fleurir des bases avec un centre qui comporte dix
praticiens, et on crée un deuxième centre quand il y en a un onzièm e
praticien dans le même centre. C'est juste un exemple.
Sur Merise on trouve des docs pas trop mal fichues, il y a des gens qui
proposent des formations aussi. En deux semaines on peut avoir une
initiation valable.
La création dynamique de champs est utile dans certaines situations.
Notamment, quand on a déployé une base de données, et que la base d e
traitement prend en compte un nouveau champ : la base de traitement doit
alors créer le nouveau champ par code, sinon on est tranquille qu'un
jour ou l'autre on va se tromper de base de données et se retrouver ave c
le message "champ inconnu".
En dehors de cela, l'interface utilisateur ne me paraît pas attirer de
reproche majeur, ça va quand même plus vite de créer un champ avec, que
d'écrire le code pour le faire, puis l'exécuter. Une réserve quand même,
c'est vrai que l'interface utilisateur évolue assez régulièrement, alors
que Dieu merci l'environnement de développement conserve plus de stabil ité.
Depuis environ cinq ans, les entreprises hésitent bien plus à faire
appel aux compétences, du coup les utilisateurs doivent se débrouille r
par leurs propres moyens. Quand on sera sortis de ça, ça augure des
missions de maintenance hautement joyeuses.
C'est au moins une bonne chose :)
Bonne nouvelle. C'est généralement ce qu'on me dit, mais il ne faut
jamais le considérer comme définitivement acquis.
Il me semble que Visual Basic est conçu pour être lisible par des gen s
qui ne l'ont pas appris. ça fait que l'utilisateur peut avoir une idé e
de ce qu'il y a dedans. Si jamais on s'est mal compris, je ne dirais pas
que c'est le moyen de correction par excellence parce que ça prendrait
quand même pas mal de temps à l'utilisateur, mais au moins si il veut le
lire il peut.
Quand à dire que c'est un langage merdique ... moins compact que C,
c'est sûr. Probablement ne le choisit-on pas pour les mêmes raisons.
D'ailleurs à présent, Microsoft propose de faire de la programmation
pour le pack Office avec la plateforme .Net : C#, VB.Net, C++ ...
Je n'ai pas encore vu se dessiner une demande forte là-dessus, mais
c'est une piste à ne pas négliger. Cela étant, comme il faut quand même
plus de temps pour y entrer que pour ouvrir un module VBA, c'est
probablement davantage destiné à des gens dont c'est le métier de
programmer, et qui savent poser les bonnes question grâce à une mét hode
d'analyse éprouvée. On en attend un code plus cher à produire au dé part,
mais qui est supposé durer -tant que l'aspect fonctionnel n'évolue pa s,
ou encore le système d'exploitation.
Sinon, il n'y aurait pas de raison qu'il y ait deux noms :o)
Exactement. C'est pour ça que c'est important de mettre à sa disposit ion
un champ qui lui dise qui a demandé le verrouillage et quand. Si ça
remonte à la veille, et que les utilisateurs sont bien "briefés" sur la
nécessité d'éteindre leur poste de travail le soir en partant, on s ait
que c'est un plantage et qu'on peut fermer. Si c'est récent on contacte
l'utilisateur pour savoir où il en est ...
Absolument. Vraisemblablement, pendant que quelqu'un d'autre modifie, on
peut lire, mais c'est une mauvaise idée d'autoriser la modification.
En fonction des détails fonctionnels de l'application, il peut
apparaître qu'un découpage des données soit judicieux, pour qu'une
personne modifie une partie, pendant qu'une autre modifie une autre.
Dans ce cas je verrais bien définir deux tables, bien que j'aie entendu
ériger le contraire en principe, mais si on veut que deux utilisateurs
puissent modifier deux parties d'un enregistrement en même temps, il
faut que le système d'exploitation, le système de gestion de base de
données et le langage le permettent. Je n'en connais pas d'exemple.
Oui, effectivement. D'ailleurs, selon le cas, il peut arriver qu'il soit
utile de se demander si l'utilisateur peut lire le code.
Il est à noter qu'Access propose un système de gestion de sécurité , avec
des groupes de connexion stockés dans un fichier d'extension mdw, et qu i
accorde des droits par objets (formulaires, tables ...). Ce n'est
peut-être pas une panacée, mais ça a au moins le mérite d'exister .
Effectivement. Bien réfléchir à ce qui se passe en cas de plantage, voir
si le système a le temps d'écrire dans la table de log. ça suppose un
gestionnaire d'erreur bien écrit.
Oui, c'est une idée, d'ailleurs SQL Server propose ça de façon
automatique en fonction de l'évolution d'un champ par exemple.
ça peut être une bonne idée d'en parler avec l'administrateur des m ails
de la boîte. C'est lui qui a connaissance des abus qui peuvent se
présenter, des blocages qu'il peut être amené à mettre en place,
éventuellement de finesses à apporter au protocole.
Oui, très clair, mais là, plutôt que de dire des bêtises, au suje t
d'informations qui seraient enregistrées en cache sur le disque et qui
poseraient un problème de confidentialité, je vais te laisser cherche r
toi-même :)
Pour ce qui est de la portée des variables on doit pouvoir creuser.
Tu as une base de données, à l'arrière, qui contient les données, et une
base frontale sur la machine de chaque utilisateur. A priori, les
variables globales sont au niveau de la base, pour le frontal on a
chacun la sienne. C'est une bonne idée de faire quelques tests pour bie n
avoir le coeur net quant à éviter toute ambiguïté.
De mon côté c'est la même chose mais dans d'autre domaines.
Je trouve que les bases de données sont un truc vraiment intéréssant,
( surtout si on y ajoute les connectivités qu'apporte internet, etc ... )
mais j'ai un job pointu et passionnant qui me prend tout mon temps
alors je ne veux pas m'investir dans 'encore un autre nouveau domaine'.
Soit on s'investit à fond, soit on butine, mais quand ca m'intéresse
j'y vais à fond et ca prend pas mal de temps, qui n'est plus
consacré à mon métier 'de base'. ( enfin, voilà pour l'apparté )
Je suis tout à fait d'accord, mais il y a des situations professionnelles
ou l'on est embarqué et on ne peut pas vraiment refuser.
Si tu te ballades à la campagne au bord d'une rivière
et que tu vois quelqu'un qui se noie, tu le sauveras même
si tu n'es pas sauveteur professionnel ni maitre-nageur ;o)
Y aurait-il eu confusion ? Je ne crée pas dynamiquement de champ, ni dans
les formulaires ni dans les tables. Tout cela est fixé au départ et ne bouge
plus.
( c'est déja ca )
Tout à fait.
J'ai eu ce problème avec des clients qui s'amusaient à trafiquer
les fichiers de config ( genre .INI ) ou des entrées de la base
de registres de Windows, ou carrément éditer un exécutable
avec un éditeur hexadécimal pour trafiquer les chaines ASCII.
Et quand ca plante ils se plaignent au SAV ...
Quand je constatais de tels 'sabotages' je suggèrais à
mon boss de facturer au prix fort pour inciter LEUR boss
à faire un sérieux ménage ... en général, ca marche bien.
De mon point de vue, l'utilisateur d'une base de données n'a rien à faire
dans le code VBA ni dans les créations de tables ou de formulaires.
S'il veut une fonctionnalité il la demande, et si c'est justifié, on
l'implémente.
Je plaisantais ( à demi )
On ne va pas commencer une polémique sur les langages
de programmation, mais je ne vois pas l'intérêt de multiplier
les langages dans la mesure où il en existe déja qui sont majeurs,
bien éprouvés, lisibles, et pouvant évoluer pour des besoins nouveaux.
Certains même développent (sic) un 'snobisme' parfois agacant,
en défendant bec et ongles un langage plutôt qu'un autre.
Les critères sont la fiabilité, la facilité, la lisibilité, etc.
Sorti de là c'est la même polémique que les gens
qui ont une voiture de telle ou telle marque ...
( zut, j'avais pourtant dit que je ne me laisserais
pas entrainer mais je m'y suis laissé prendre ! )
Oui.
Certes mais là je n'ai pas ce genre de problème.
La structure des données dans la base est relativement simple
( pour par exemple quelqu'un comme toi qui est un professionnel
du domaine et qui - j'imagine - en a vu bien d'autres )
donc c'est assez blindé de ce côté-là.
Pour mon appli, c'est exclu. Non seulement la modif du code
est interdite, mais même la lecture seule n'est pas souhaitable.
Là tu touches un point important. J'ai vu ca il y a quelques
années, mais je ne sais pas (encore) le mettre en place.
Ca ne va pas aussi loin. Si des données erronnées sont
dans la base, je pense juste utiliser le log pour identifier
les utilisateurs qui étaient sur la base à l'instant du plantage,
et remonter à ce qu'ils ont fait qui aurait pu causer le problème.
Là, je n'ai rien compris à ce que tu dis :o)
Oui, je vais faire ca.
C'est intéréssant d'avoir à la fois des variables propres à chaque
session ET des variables identiques pour toutes les sessions.
Par exemple :
Les droits utilisateurs sont propres à chacun
donc les variables qui y font référence doivent être
LOCALES à chaque PC qui ouvre la base via le réseau.
Si ce n'est pas le cas et que ces variables sont globales,
un utilisateur de bas niveau ayant des droits restreints
pourrait se retrouver avec des droits plus élevés
( et faire des modifs interdites )
Inversement, un utilisateur de haut niveau ayant des droits
étendus pourrait se retrouver avec des droits restreints
et ne pourrait plus utiliser la base à cause des restrictions.
D'un autre côté, une variable GLOBALE pourrait être mise à jour
à chaque fois qu'un utilisateur se connecte ou se déconnecte :
cela pemettrait de connaitre le nombre d'utilisateurs connectés
sur la base à un instant T ... (par exemple pour faire du 'ménage'
ou du back-up automatiquement quand personne n'est connecté)
Mais j'ai un sérieux doute quand à l'existence de variables
globales en VBA sur différentes sessions sur différents PC :
car cela implique que, lors de la modif de cette variable globale sur
n'importe lequel des postes utilisateurs, Access doit maintenir la valeur
de cette variable en la mettant à jour toutes les sessions en cours,
tout cela via le réseau, etc. Je ne sais pas pourquoi, mais j'ai un doute.
PS : Ce ne sont là que des exemples.
Ah ben oui. Pour ma part j'ai laissé tomber ce que je faisais avant pou r
me consacrer à l'informatique, et je ne regrette pas. Alors il a dû y
avoir des gens qui ont été tentés par ce chemin pour la sécurité de
l'emploi, pour eux ça doit être dur, en ce moment. Pour les autres au ssi
d'ailleurs mais si au moins on fait quelque chose qu'on aime c'est déjà ça.
Là aussi il y a plusieurs niveaux. Si on arrive avec juste sa bonne
volonté on peut tendre la main avant que la personne se noie, si on
arrive juste un peu après c'est trop tard.
Après il y a le niveau premier secours, qui prend une semaine environ à
acquérir, plus un rafraichissement d'un week-end chaque année, ça p ermet
de parer au plus pressé en attendant que les vrais secours arrivent. On
met sur le côté pour que la victime ne s'étouffe pas en vomissant, si
elle ne respire plus on masse la respiration et le coeur, on fait
appeler les secours en leur fournissant les bons renseignements, en
précisant bien de ne pas raccrocher sans l'accord de la personne qui a
répondu. ça permet de tenir vingt minutes le temps que les pompiers
arrivent, un peu plus quelquefois (a priori on doit s'entraîner pour
être capable de pomper quarante minutes, là suffit pas de le dire -c' est
plus facile si on est plusieurs d'ailleurs).
Puis le niveau vrai secouriste, qui s'est formé en deux à trois
semaines, pour faire des permanences sur les grands rassemblements, une
fois équipé est capable de prendre en charge une palette plus vaste d e
problèmes, et de remettre les victimes d'aplomb sans qu'il soit besoin
d'autre intervention derrière.
Le niveau après, à ma connaissance, c'est professionnel de santé, d u
coup il y a un écart de niveau plus important (la standardiste je ne
sais pas, mais c'est clair que pour être médecin ...)
Tu n'avais pas dit que tu le faisais par VBA ?
ça, me rappelle que j'y ai joué, une fois, avant d'être informatici en.
J'ai modifié un octet dans le pilote de clavier, pour que les majuscule s
restent verrouillées jusqu'à appuyer une deuxième fois sur verrouil lage
majuscules. Je n'étais pas mécontent de mon fait. Mais avec la versio n
suivante ce n'était plus possible.
Mais j'avais fait une copie, avant.
Ouaip
C'est vrai que le langage fourni avec le produit encourage une confusion
des rôles. ça aide ceux qui ont la vocation à s'initier au départ , et
après ils se forment pour de bon pour franchir le pas, mais ceux qui ne
l'ont pas vraiment pataugent un peu dedans et laissent du bazar derrièr e
eux.
On ne devrait pas pousser vers là des gens qui n'en ont pas envie.
un peu pour ce que je viens de dire ?
C'est vrai, la co-existence de C# et VB.Net relève plus du marketing qu e
d'autre chose. Enfin si ça aide Microsoft à gagner sa croûte ...
Ah c'est vrai qu'il faut prendre le temps de lire la doc et
d'expérimenter. En fait je l'ai fait une fois, pour le refaire il
faudrait que je me replonge dedans. Et c'est peu probable, vu que à que l
point j'ai déjà un pied sur .Net ...
Ah, oui, on a écrit ça avant le plantage ?
Mais ça n'empêche pas d'avoir des procédures d'erreur propres, ça ne
prend pas des mois à apprendre à faire ...
Et d'ailleurs, ça permet de fermer la table, ça évite de perdre les
écritures en cours (ah oui attention, si tu ne fermes pas ta table, tu
risques de ne pas savoir qui était là).
Si tu manipules des données hautement confidentielles, ça serait bien de
faire venir quelqu'un dont c'est le métier de veiller au grain. Je ne
suis même pas sûr que je m'y frotterais.
Je me rappelle avec une des premières versions de Word, on pouvait
mettre un mot de passe sur chaque document. Sauf qu'on pouvait afficher
le document avec la commande TYPE du DOS, ça n'affichait pas le contenu ,
mais ça affichait le mot de passe en clair.
Plus tard, j'ai jeté un coup d'oeil dans un document d'une autre
version, j'ai lu dans le premier secteur des informations qui n'avaient
absolument rien à voir. Des adresses client, par exemple, qui n'avaient
rien à voir avec le destinataire du document. Tout ça dans un courrie r,
selon à qui tu l'envoies ça peut faire mal.
Quand on consulte un fichier présent sur un CD, le système en fait un e
copie en local sur le disque dur, pour pouvoir y avoir accès en
écriture, ça lui permet de gérer les verrouillages par exemple. Je
n'affirmerais pas qu'il n'en aille pas de même d'un fichier lu depuis u n
réseau. Avec des nuances puisque le réseau permet de le modifier.
Donc, en admettant que le fichier sur le réseau soit sécurisé avec un
mot de passe, il faut quand même avoir conscience que sa copie dans le
tampon ne l'est pas. En règle générale on ne s'en préoccupe pas, mais il
faut avoir conscience que l'espionnage industriel existe. Le plus
souvent un programmeur n'a pas toutes les compétences pour l'éviter,
mais réfléchir à des questions pratiques comme celle-là permet de
limiter les dégâts.
Oui et non. Les règles de sécurité sont communes à toute l'applic ation.
Il est vrai qu'il faut prendre des précautions pour que n'importe qui n e
puisse pas modifier la table qui définit les droits.
Il est vrai qu'on peut utiliser plusieurs approches.
L'autre jour quelqu'un a proposé une méthode du trousseau de clefs,
basée sur un octet dont chaque bit définit un droit, et chaque
utilisateur se voit confier un trousseau qui prend la forme d'un octet.
Il n'empêche que l'octet en question, il faut être sûr de l'attribu er de
manière fiable à l'utilisateur.
Oui à ce moment tu ne mets pas ça dans la base frontale, mais dans la
base de données derrière (a priori dans une table), puisque c'est à elle
que tu veux savoir combien il y a de personnes connectées. Attention à
ce qui se passe si deux personnes se connectent en même temps.
ça n'empêche pas d'y accéder par une table liée, d'ailleurs.
Et bien entendu il faut gérer le problème du plantage, au cours du qu el
quelqu'un se déconnecte sans décrémenter le compteur.
D'ailleurs, dans une table je stockerais bien le nom de l'utilisateur
qui se connecte, celui de sa machine, son adresse IP, et la date et
l'heure. ça permet de savoir qui est connecté et où, et depuis comb ien
de temps. Pour ce qui est de savoir depuis combien de temps, ça permet
de gérer les plantages, on en a déjà parlé.
Là je croirais assez à la table de paramètres, ou d'options qui
généralement n'a qu'un seul enregistrement.
C'est vrai que les variables globales sous Access, ça me laisse un peu sec.
Avant de remettre un trousseau de clefs à quelqu'un, je m'assure de son
identité à l'aide d'un login et d'un mot de passe. C'est élémentaire me
semble-t-il ? Cela permet aussi de suivre cette personne en établissant
un mouchard des actions importantes.
Les formulaires et tables sont créés 'à la main' via l'interface Access,
et après ils ne bougent plus ; ils sont définis une fois pour toutes.
Ce que je fais en VBA c'est gérer tous les évènements liés aux
lectures/écritures des éléments des formulaires et des données
dans les tables, assurer la cohérence, gérer les droits d'accès, etc ...
Ok, mais ca, ce n'est pas du 'sabotage' ...
Ce que je reproche au Visual Basic est d'être assez opaque et
même parfois subtilement incompatible entre certaines versions.
Mais tout ca c'est la logique commerciale de MS.
Il n'est pas question de gérer les plantages mais de
remonter à la cause d'éventuelles données erronnées.
Je ne comprends pas trés bien ta remarque. La table de log n'est
pas ouverte en début de session puis fermée en fin de session,
sinon en cas de crash je perdrais les écritures encore dans le cache.
Pour être plus précis, j'ai écrit une fonction qui prend en paramètre
une chaine ( décrivant l'évènement à mémoriser ) cette fonction ouvre
la table de log et y inscrit { user login , date/time , l'évènement }
puis ferme la table avant de rendre la main. La table n'est accédée en
écriture que pendant le court temps d'y inscrire un seul enregistrement.
On peut toujours imaginer qu'il y ait un crash justement à l'instant
où l'on exécute le code de cette fonction, mais cette probabilité
est plus faible que si la table était tout le temps ouverte.
Les données sont bien confidentielles et le niveau de
protection dont tu parles est assuré par l'admin IT de la boite.
Je lui ai demandé de bétonner l'accès de la base au niveau
réseau et serveur, avec la liste des seuls utilisateurs autorisés.
( qui sont eux-même les sources de ces données confidentielles,
ils sont donc 'trusted' puisqu'ils connaissent déja ces données )
Même par 'accident' personne d'autre ne peut y accéder, même pas
en lecture seule, et ceci n'est pas à ma charge mais à celle de l'admin IT.
Oui je suis bien conscient des problèmes que tu soulèves,
mais cette partie du travail est à la charge de l'admin IT.
Oui, c'est bien ce dont je parlais.
Là je suis à nouveau largué :
Il n'y a qu'un seul fichier ACCDB, il n'y a qu'une seule base.
Pourquoi parles-tu de deux bases ( frontale & derrière ) ?
Tout çà fait.
C'est ce que je fais avec ma fonction log.
Mmmmh ...
Ah, d'acc ...
:)
Ah oui le coup de l'apprenti sorcier ...
Ah, c'est marrant que tu trouves le VB opaque par rapport à C ...
Ah, oui, c'est une solution.
Remarque bien que l'un n'empêche pas l'autre ...
Effectivement, j'imagine que c'est au-dessus de la moyenne ...
Tu n'as pas dit que plusieurs utilisateurs accédaient à l'application ?
Tu ne leur fais quand même pas ouvrir via le réseau une base qui
contient à la fois les données et le traitement ?
Bien. Ah oui alors pour la lecture tu parcours le log, tu dis celui-là,
qui est entré là, est reparti à cette ligne-là ...
C'est ça ?