Eviter plusieurs accés simultanés à un recordset.

Blaise a écrit, le 15/09/2012 18:47 :

Avant de remettre un trousseau de clefs à quelqu'un, je m'assure de s on
identité à l'aide d'un login et d'un mot de passe. C'est éléme ntaire me
semble-t-il ? Cela permet aussi de suivre cette personne en établiss ant
un mouchard des actions importantes.

Ah ben oui.
Sauf qu'une base de données fonctionne un peu sur le principe d'un hô tel
: en sortant on met sa clef sur le tableau pour que le ménage puisse
être fait (enfin à quelques nuances près, l'allégorie vaut ce qu' elle
vaut ...)

Il faut faire bien attention, dans les options, de mettre le tableau de
clefs derrière l'accueil, plutôt que dans la rue comme c'est le cas p ar
défaut :)

"Gloops" .

tu ne mets pas ça dans la base frontale, mais dans la base de données
derrière

| 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 ) ?

Tu n'as pas dit que plusieurs utilisateurs accédaient à l'application ?

Oui.

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 ?

Si. Je te vois presque sursauter ...
mais c'est pourqoi je te re-pose ma question précédente :
pourquoi plusieurs bases ?

John a écrit, le 17/09/2012 18:09 :

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 ?

Si. Je te vois presque sursauter ...
mais c'est pourqoi je te re-pose ma question précédente :
pourquoi plusieurs bases ?

C'est la façon habituelle de travailler :
- ça facilite les mises à jour, car on peut modifier le code sans
toucher aux données
- ça allège le trafic sur le réseau, car il n'y a que les données qui
passent -à condition de mettre un exemplaire de la base frontale sur le
poste de chaque utilisateur.

Entre les deux, le lien se fait en général par les tables liées, qu i au
demeurant servent à ça.

D'ailleurs, je me demande bien comment on peut travailler à plusieurs
sur la même base, si l'interface est dans le même fichier, donc par v oie
de conséquence sur la même machine.

C'est à telle enseigne qu'Access propose un assistant pour effectuer le
fractionnement.

"Gloops" :

pourquoi plusieurs bases ?

C'est la façon habituelle de travailler :
- ça facilite les mises à jour, car on peut modifier le code sans toucher
aux données

Oui, ca c'est une (trés bonne) bonne raison.

- ça allège le trafic sur le réseau, car il n'y a que les données qui
passent -à condition de mettre un exemplaire de la base frontale sur le
poste de chaque utilisateur.

Voilà peut-être un drawback : lors d'une mise à jour de
la base frontale il faut veiller à ce que tout le monde soit ok,
( mais ce n'est pas rédhibitoire )
alors qu'avec un seul fichier, tout est forcément à jour.

Entre les deux, le lien se fait en général par les tables liées, qui au
demeurant servent à ça.

D'ailleurs, je me demande bien comment on peut travailler à plusieurs sur
la même base, si l'interface est dans le même fichier, donc par voie de
conséquence sur la même machine.

D'où une de mes questions d'un post précédent :
si deux utilisateurs, depuis leurs machines A et B en réseau,
ouvrent une base ACCDB située sur une 3e machine C en réseau,
quels sont les éléments de la base C (données des tables, etc)
qui sont transférés et/ou synchronisés vers A et B
et quels sont ceux qui restent sur C ?

John a écrit, le 18/09/2012 19:01 :

"Gloops" :

pourquoi plusieurs bases ?

C'est la façon habituelle de travailler :
- ça facilite les mises à jour, car on peut modifier le code sans
toucher aux données

Oui, ca c'est une (trés bonne) bonne raison.

N'est-ce pas ?

Dans l'interface utilisateur il existe un gestionnaire de tables liées,
pour changer la base source pour toutes les tables à la fois. Cela ét ant
dit, concrètement, on ne va pas aller tous les mois derrière l'épau le de
chaque utilisateur, pour lui dire il faut cliquer là, non non là, oui ,
puis là, et ensuite là ...

Donc, dans la procédure de mise à jour du code, on va introduire une
fonction de mise à jour des liens, table liée par table liée. On tr ouve
ça tout prêt sur Internet, au besoin.

- ça allège le trafic sur le réseau, car il n'y a que les donné es qui
passent -à condition de mettre un exemplaire de la base frontale sur
le poste de chaque utilisateur.

Voilà peut-être un drawback : lors d'une mise à jour de
la base frontale il faut veiller à ce que tout le monde soit ok,
( mais ce n'est pas rédhibitoire )
alors qu'avec un seul fichier, tout est forcément à jour.

Pas dur, ça. Dans la table de paramètres on peut très bien mettre u n
champ avec date et heure de mise à jour du code. A chaque chargement, l a
base frontale lit ça, et comme elle sait quand elle a été créée , si la
date de mise à jour est plus récente :
- je dis à l'utilisateur que je ne suis pas à jour
- je déclenche le téléchargement
- j'indique à l'utilisateur où il faut cliquer
- je vais me coucher parce que tout ça m'a bien fatigué :)

C'est le principe, on peut affiner plus la procédure de mise à jour.

Entre les deux, le lien se fait en général par les tables liées, qui
au demeurant servent à ça.

D'ailleurs, je me demande bien comment on peut travailler à plusieur s
sur la même base, si l'interface est dans le même fichier, donc pa r
voie de conséquence sur la même machine.

D'où une de mes questions d'un post précédent :
si deux utilisateurs, depuis leurs machines A et B en réseau,
ouvrent une base ACCDB située sur une 3e machine C en réseau,
quels sont les éléments de la base C (données des tables, etc)
qui sont transférés et/ou synchronisés vers A et B
et quels sont ceux qui restent sur C ?

Pas dur, on crée des tables liées vers toutes les tables de la base C ,
comme ça on dispose de toutes les données. Si une table n'a pas à ê tre
mise à jour, on ne crée pas d'interface utilisateur qui la modifie.

La table des paramètres (ou des options) est un cas particulier : on me t
à jour champ par champ, sur demande, et toujours sur le même
enregistrement. On peut préciser une clef quand même, des fois qu'un
jour on veuille conserver un jeu de paramètres en historique, et en
utiliser un autre. ça peut arriver, que les paramètres s'ajustent en
fonction de quelque chose à quoi on n'avait pas pensé.

Gloops a écrit, le 19/09/2012 19:00 :

La table des paramètres (ou des options) est un cas particulier : on met
à jour champ par champ, sur demande, et toujours sur le même
enregistrement. On peut préciser une clef quand même, des fois qu'u n
jour on veuille conserver un jeu de paramètres en historique, et en
utiliser un autre. ça peut arriver, que les paramètres s'ajustent e n
fonction de quelque chose à quoi on n'avait pas pensé.

D'ailleurs, on peut avoir une table d'options sur la base source, qui
est commune à tout le monde, et une table de paramètres (non liée) sur
la base frontale, qui va être propre à l'utilisateur, où il pourra
adapter les éditions à son imprimante par exemple.

La date d'arrêté comptable est clairement commune à tout le monde,
d'autres champs peuvent mériter plus de réflexion.

Généralement mes noms de table commencent par tab.
Il arrive que certaines tables ne fassent pas l'objet d'une liaison,
leur nom pourra alors commencer plutôt par tbl. Comme ça, on parcourt
toutes les tables, mais on ne met à jour les liaisons que de celles don t
le nom commence par le préfixe idoine.

Ne pas oublier qu'il existe des tables système, dont le nom commence pa r
Sys, qui par défaut ne sont pas visibles dans l'interface utilisateur,
mais qui font partie de la collection Database.TableDefs
Donc on n'y coupera pas, il faut parcourir la collection des tables, et
pour chacune effectuer un test pour savoir si elle doit faire l'objet du
traitement.

For Each Tb in CurrentDb().TableDefs
If Left$(Tb.Name, 3) <> "Sys" Then
Debug.Print Tb.Name
End If
Next

"Gloops" :

pourquoi plusieurs bases ?

C'est la façon habituelle de travailler :
- ça facilite les mises à jour, car on peut modifier le code sans
toucher aux données

Oui, ca c'est une (trés bonne) bonne raison.

N'est-ce pas ?

Dans l'interface utilisateur il existe un gestionnaire de tables liées,
pour changer la base source pour toutes les tables à la fois. Cela étant
dit, concrètement, on ne va pas aller tous les mois derrière l'épaule de
chaque utilisateur, pour lui dire il faut cliquer là, non non là, oui,
puis là, et ensuite là ...

Donc, dans la procédure de mise à jour du code, on va introduire une
fonction de mise à jour des liens, table liée par table liée. On trouve ça
tout prêt sur Internet, au besoin.

- ça allège le trafic sur le réseau, car il n'y a que les données qui
passent -à condition de mettre un exemplaire de la base frontale sur
le poste de chaque utilisateur.

Voilà peut-être un drawback : lors d'une mise à jour de
la base frontale il faut veiller à ce que tout le monde soit ok,
( mais ce n'est pas rédhibitoire )
alors qu'avec un seul fichier, tout est forcément à jour.

Pas dur, ça. Dans la table de paramètres on peut très bien mettre un champ
avec date et heure de mise à jour du code. A chaque chargement, la base
frontale lit ça, et comme elle sait quand elle a été créée, si la date de
mise à jour est plus récente :
- je dis à l'utilisateur que je ne suis pas à jour
- je déclenche le téléchargement
- j'indique à l'utilisateur où il faut cliquer
- je vais me coucher parce que tout ça m'a bien fatigué :)

C'est le principe, on peut affiner plus la procédure de mise à jour.

Entre les deux, le lien se fait en général par les tables liées, qui
au demeurant servent à ça.

D'ailleurs, je me demande bien comment on peut travailler à plusieurs
sur la même base, si l'interface est dans le même fichier, donc par
voie de conséquence sur la même machine.

D'où une de mes questions d'un post précédent :
si deux utilisateurs, depuis leurs machines A et B en réseau,
ouvrent une base ACCDB située sur une 3e machine C en réseau,
quels sont les éléments de la base C (données des tables, etc)
qui sont transférés et/ou synchronisés vers A et B
et quels sont ceux qui restent sur C ?

Pas dur, on crée des tables liées vers toutes les tables de la base C,
comme ça on dispose de toutes les données. Si une table n'a pas à être
mise à jour, on ne crée pas d'interface utilisateur qui la modifie.

La table des paramètres (ou des options) est un cas particulier : on met à
jour champ par champ, sur demande, et toujours sur le même enregistrement.
On peut préciser une clef quand même, des fois qu'un jour on veuille
conserver un jeu de paramètres en historique, et en utiliser un autre. ça
peut arriver, que les paramètres s'ajustent en fonction de quelque chose à
quoi on n'avait pas pensé.

Ok.

Effectivement je devrais splitter la base "unique"
en une base de données "arrière" et des interfaces "frontales",
et j'ai aussi noté le coup de "tables liées" ( je ferai des tests ).

Merci encore pour ton aide précieuse.

John a écrit, le 19/09/2012 19:34 :

Ok.

Effectivement je devrais splitter la base "unique"
en une base de données "arrière" et des interfaces "frontales",
et j'ai aussi noté le coup de "tables liées" ( je ferai des tests ) .

Merci encore pour ton aide précieuse.

Dis si des problèmes se présentent ...