Limites d'Access dans la pratique

**buzz73** · 20/05/2009, 10h10

Bonjour,

J'ai commencé à développer une base de données Access qui devait être utilisée initialement par 4 personnes puis on m'a demandé pour 20 et maintenant peut-être pour 60 ou 80 personnes. (toutes en lecture et écriture)

1. Access sera-t-il capable de gérer toutes ces utilisateurs en même temps? (théoriquement c'est 255 utilisateurs mais en pratique?)
2. J'ai aussi des macros qui permettent de créer des enregistrements dans des tables, trop d'accès simultanés à une table ça peut se produire? (je ne suis pas du tout à l'aise sur cette partie, je ne sais pas comment sont gérés les accès multiples à une table etc)
3. Avez-vous des liens pour que je comprenne la partie multi-utilisateurs d'Access (je viens d'Excel alors on en est loin)

J'ai vu que la taille d'une base Access est limitée, donc si on supprime purement et simplement des enregistrements, cela suffira-t-il? (je n'ai besoin que de 4 ans d'historique)

Par la suite, peut-on mettre Access sur un intranet? Cela est-il difficile a mettre en place et surtout à gérer?

**Tofalu** · 20/05/2009, 12h27

Bonjour,

A vous lire, Access ne semble pas correspondre à vos nouveaux besoins.

80 personnes : c'est beaucoup beaucoup trop
4 ans d'historique : ça peut vite faire une très grosse base vu le nombre d'utilisateur
Intranet : Non, pas du tout adapté

Je vous conseille plutot de vous orienter vers SQL Server pour les données et conserver l'application sous Access

**buzz73** · 20/05/2009, 13h17

Merci pour ta réponse Tofalu!

Une base Access peut gérer correctement combien d'utilisateurs en simultanée?

**Tofalu** · 20/05/2009, 13h20

1

Plus sérieusement, tout va dépendre de la taille et des accès à la base. Sans compter la qualité du réseau, car on est sur une architecture client/serveur.
Passé la dizaine, tu auras pas mal de difficultés à avoir quelque chose d'utilisable en lecture/écriture.

**buzz73** · 20/05/2009, 13h28

10 ça fait peu...

Je te conseille plutot de t'orienter vers SQL Server pour les données et conserver l'application sous Access

Comment fonctionnerai un couple SQL Server / Access ?
Je ne connais pas du tout SQL Server... ce serait pour stocker les données et Access serait l'interface?

**Tofalu** · 20/05/2009, 16h59

Envoyé par buzz73

10 ça fait peu...

Comment fonctionnerai un couple SQL Server / Access ?
Je ne connais pas du tout SQL Server... ce serait pour stocker les données et Access serait l'interface?

Tout à fait.

Et au lieu d'avoir une base frontale mdb, tu aurais ce que l'on appelle un projet Access adp ou ade (si compilé)

Il doit y avoir un tutoriel qui traine là dessus. Essaye de voir à cette adresse http://access.developpez.com/cours

**buzz73** · 20/05/2009, 18h27

J'ai trouvé le lien :
http://argyronet.developpez.com/office/access/mdb2adp/

Donc je peux tranquillement terminer mon application 100% access puis par la suite la faire migrer c'est bien ça?

**cbleas** · 20/05/2009, 19h39

Bonjour,
il est préférable de passer directement en sql serveur car il y aura des différences comme le montre le lien.
Il ne faut pas oublier le cout car pour 60 utilisateurs cela ne sera pas faible.
en effet la version sql Server 2005 express est limité à 4 Go de données à 1 G0 de RAM et enfin optimisé à 20 utilisateur ce qui n'empeche pas de le faire fonctionner pour 80 utilisateurs.
Bonne journée

**loufab** · 21/05/2009, 13h40

A moindre modif on peut utiliser SQL server avec des tables attachées et faire du DAO. Pour les gros traitements couteux on passe en ADO avec du SQL Direct.

ça fonctionne pas trop mal.

**buzz73** · 25/05/2009, 15h40

Bon je vais finir mon application Access puis je vais me pencher là dessus.

Merci à tous pour vos réponses!

**=JBO=** · 25/05/2009, 18h38

Bonjour,

Tant pis si je passe pour un "pinailleur"...

Envoyé par loufab

A moindre modif on peut utiliser SQL server avec des tables attachées et faire du DAO.
Pour les gros traitements couteux on passe en ADO avec du SQL Direct.

Le SQL Direct c'est possible aussi avec DAO.

Envoyé par buzz73

2. J'ai aussi des macros qui permettent de créer des enregistrements dans des tables, trop d'accès simultanés à une table ça peut se produire? (je ne suis pas du tout à l'aise sur cette partie, je ne sais pas comment sont gérés les accès multiples à une table etc)

Pour répondre juste sur l'ajout d'enregistrements...
La manière de gérer l'ajout d'un enregistrement au niveau de Jet (le moteur de bases de données d'Access) garantit qu'il n'y a jamais de conflits entre n ajouts simultanés dans une même table, à moins de violer les contraintes d'intégrité (bien évidemment).
Mais en tout cas, il n'y a pas de problème de verrouillage.
_

**buzz73** · 26/05/2009, 09h01

Merci pour ces indications supplémentaires (je suis rassuré

)

J'ai une question supplémentaire :
J'ai une table qui est constamment vidée et remplie à nouveau afin de mettre à jour une autre table. Cela se fait suite à une action bien particulière de changement de quantité.
Peut-on rencontrer des problèmes si plusieurs personnes font cette action au même moment? (elle dure quelques secondes mais Loi de Murphy oblige

) Et si oui quel type de problème?

Si par exemple il y a 3 actions consécutives sur la table pour que tout soit ok, peut-il y avoir une action extérieure entre 2 actions et donc corrompre les données?

**=JBO=** · 26/05/2009, 13h31

Bonjour,

A ce stade de la discussion, si tu choisis de développer en MDB, il me semble clair que tu auras une architecture de type "base dorsale (les données) - base frontale (l'application)".
- La base dorsale (les données) est placée sur un serveur de fichiers, dans un dossier partagé.
- La base frontale (l'application) est copiée sur chaque PC utilisateur.

Envoyé par buzz73

J'ai une question supplémentaire :
J'ai une table qui est constamment vidée et remplie à nouveau afin de mettre à jour une autre table. Cela se fait suite à une action bien particulière de changement de quantité.
Peut-on rencontrer des problèmes si plusieurs personnes font cette action au même moment? (elle dure quelques secondes mais Loi de Murphy oblige

) Et si oui quel type de problème?

Si par exemple il y a 3 actions consécutives sur la table pour que tout soit ok, peut-il y avoir une action extérieure entre 2 actions et donc corrompre les données?

Bien sûr qu'il risque d'y avoir des conflits (un utilisateur ajoute, pendant qu'un autre vide la table

, et toutes les combinaisons sont possibles).

Je vois 2 problèmes:
- sur la table temporaire (constamment vidée et remplie),
- sur la table qui doit être mise à jour.

Pour la table temporaire, le mieux est d'en faire une table de travail locale à la base frontale, comme ça elle n'est jamais partagée.

Pour la mise à jour d'une table (celle-ci placée dans la base dorsale) le plus simple est d'exécuter la requête de mise à jour en spécifiant une option qui interdit l'écriture simultanée par plusieurs utilisateurs.

Par exemple, en DAO:

Code VBA :

Sélectionner tout - Visualiser dans une fenêtre à part

CurrentDB.Execute "nom d'une requête de mise à jour", dbDenyWrite + dbFailOnError

Ce code garantit que les mises à jour seront effectuées à la condition qu'il n'y ait pas de conflit d'écriture.
Sinon, aucune mise à jour n'est effectuée et une erreur est générée pour que le programme puisse prendre les mesures qui s'imposent (par exemple, effectuer une nouvelle tentative après un un certain délai ).
_

**buzz73** · 26/05/2009, 14h36

N'étant pas encore à l'aise avec tout ça, je vais prendre l'option d'écriture par un seul utilisateur à la fois pour cette table particulière. Théoriquement, elle ne devrait pas être trop utilisée donc avec ton code ça devrai être tout bon.
Merci!

Euh...
Comment on utilise ce code? Actuellement, dans l'événement AfterUpdate d'un contrôle je lance une macro qui lance différentes requêtes. Et c'est justement pendant cette macro que j'aimerai interdire les modifications sur la table qui est vidée et re-rempli( table1)
De plus, je dois aussi interdire les modifications par les autres utilisateurs sur la table (table2) qui est ensuite mise à jour à partir de de la table1 ou le moteur Jet gère déjà tout tout seul?

(si vous avez des tuto ou des bouts de cours sur cette partie je veux bien car je nage là...)

**=JBO=** · 27/05/2009, 10h13

Bonjour,

Envoyé par buzz73

Euh...
Comment on utilise ce code? Actuellement, dans l'événement AfterUpdate d'un contrôle je lance une macro qui lance différentes requêtes. Et c'est justement pendant cette macro que j'aimerai interdire les modifications sur la table qui est vidée et re-rempli( table1)
De plus, je dois aussi interdire les modifications par les autres utilisateurs sur la table (table2) qui est ensuite mise à jour à partir de de la table1 ou le moteur Jet gère déjà tout tout seul?

Si tu veux que nous puissions t'aider concrêtement, tu devrais nous donner le code de la procédure événementielle _AfterUpdate().

Concernant table1, si tu effectues un découpage dorsale-frontale, et que tu places table1 dans la base frontale, alors il n'y aura pas de conflit car cette table sera accédée en mono-utilisateur.

Pour la mise à jour de table2, merci de nous donner ton code. Nous pourrons te montrer comment l'adapter.
_

**buzz73** · 27/05/2009, 10h54

Pour la procédure événementielle, je suis passé par le mode graphique donc dans "Après Maj", j'ai la macro :
M_QteBoxChange_Maj_T_QtePromo_Temp

Voici ce qu'elle fait :

Arrêt des avertissements
Lancement d'une requête qui vide table1
J'ai ajouté un "ExécuterCommande" qui actualise.
Je remplis table1 (clé primaire sur 2 champs) avec les résultats d'une requête qui fait des regroupements et qui somme les quantités
Je mets à jour les quantités de table2 si les enregistrements sont présents dans table1 => Qtés
Je mets à 0 les enregistrements de table2 qui ne sont pas présents dans table1
Je remets les avertissements

Concernant table1, si tu effectues un découpage dorsale-frontale, et que tu places table1 dans la base frontale, alors il n'y aura pas de conflit car cette table sera accédée en mono-utilisateur.

J'en ai effectivement entendu parlé mais je ne sais pas faire ça.
Pour le moment j'apprends à faire l'application puis je vais devoir apprendre à faire ça.
Est-ce que je peux mettre la base sur un fichier commun à tout le monde (dans un fichier à mon nom, c'est ce que je comptais faire par la suite) ne contenant que les tables et créer un .mdb (je crois que c'est celui là qui sert de client c'est ça) que j'aurais sur mon pc et quand même continuer de développer mon application? Comme ça je pourrai mettre table1 en frontale (elle ne sera donc pas sur le fichier commun c'est bien ça?).

ps : c'est sympa de s'occuper de mon problème, merci.

**=JBO=** · 27/05/2009, 11h12

Pour commencer tu devrais convertir la macro Access M_QteBoxChange_Maj_T_QtePromo_Temp en une procédure VBA.

Dans la fenêtre de Base de données, tu sélectionnes la macro.
Puis dans le menu Outils, sous-menu Macro, tu exécutes la commande:
Convertir les macros en Visual Basic.

Un nouveau module de code est créé avec le code VBA équivalent à la macro Access.
Ouvre ce module de code (il est affiché dans VBE, Visual Basic Editor, l'environnement de développement de VBA), copie le code et envoie le nous.

Merci !

**buzz73** · 27/05/2009, 15h44

Je ne connaissais pas la manip.
C'est très intéressant de pouvoir voir le contenu des macros

Voici le code de M_QteBoxChange_Maj_T_QtePromo_Temp

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
'------------------------------------------------------------
' M_QteBoxChange_Maj_T_QtePromo_Temp
'
'------------------------------------------------------------
Function M_QteBoxChange_Maj_T_QtePromo_Temp()
On Error GoTo M_QteBoxChange_Maj_T_QtePromo_Temp_Err
 
    DoCmd.SetWarnings False
    ' vider T_QtePromo_Temp
    DoCmd.OpenQuery "R_Vider_T_QtePromo_Temp", acViewNormal, acEdit
    DoCmd.RunCommand acCmdRefresh
    ' Ajout_T_QtePromo_Temp
    DoCmd.OpenQuery "R_Ajout_T_QtePromo_Temp avec R_QtePromo_IDArt_IdEnseigne", acViewNormal, acEdit
    ' Maj FcstKAM_ Qte Art ds promo
    DoCmd.OpenQuery "R_Maj_FcstKAM_QtePromo avec T_QtePromo_Temp", acViewNormal, acEdit
    ' Maj FcstKAM_QtePromo à 0
    DoCmd.OpenQuery "R_Maj_FcstKAM_ArticleSansQtePromo", acViewNormal, acEdit
    DoCmd.SetWarnings True
 
 
M_QteBoxChange_Maj_T_QtePromo_Temp_Exit:
    Exit Function
 
M_QteBoxChange_Maj_T_QtePromo_Temp_Err:
    MsgBox Error$
    Resume M_QteBoxChange_Maj_T_QtePromo_Temp_Exit
 
End Function

**=JBO=** · 27/05/2009, 19h09

Voilà une proposition de réécriture de la macro Access, en utilisant la bibliothèque DAO pour l'accès aux données (au lieu de ADO).

Donc, pour que ce code soit compilé sans erreur et qu'il puisse fonctionner, il faut ajouter une référence à bibliothèque DAO.

Code VBA :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
Public Sub QteBoxChange_Maj_FcstKAM()
    Dim oDB As DAO.Database
    Dim sMsg As String
    Dim eResult As VBA.VbMsgBoxResult
 
    Set oDB = Application.CurrentDb
 
    ' 2. vider T_QtePromo_Temp
    oDB.Execute "R_Vider_T_QtePromo_Temp"
 
    ' 3. actualiser
    DoCmd.RunCommand acCmdRefresh
 
    ' 4. Ajout_T_QtePromo_Temp
    oDB.Execute "R_Ajout_T_QtePromo_Temp avec R_QtePromo_IDArt_IdEnseigne"
 
On Error GoTo ErreurConflit
 
    ' 5. Maj FcstKAM_ Qte Art ds promo
    oDB.Execute "R_Maj_FcstKAM_QtePromo avec T_QtePromo_Temp", dbDenyWrite + dbFailOnError
 
    ' 6. Maj FcstKAM_QtePromo à 0
    oDB.Execute "R_Maj_FcstKAM_ArticleSansQtePromo", dbDenyWrite + dbFailOnError
 
Fin:
    Set oDB = Nothing
    Exit Sub
 
ErreurConflit:
    If Err.Number = 3008 Then
        sMsg = "Conflit d'écriture sur la table FcstKAM." & vbCrLf & "Voulez-vous essayer à nouveau ?"
        eResult = MsgBox(sMsg, vbCritical + vbRetryCancel)
 
        If eResult = vbRetry Then Resume        
    Else
        MsgBox Err.Description & Err.Number, vbCritical, "Erreur !"
    End If
 
    Resume Fin
 
End Sub