Discussion :

[jmareal]

Bonjour,
j’utilise depuis plus de 10 ans une application de gestion Access (2002 puis 2016). Une frontale et une dorsale.
L’application fonctionne en réseau multipostes. Chez la plupart de mes clients tout va bien.
Chez certains (rares heureusement) j’ai parfois (une fois tous les 2 mois de façon irrégulière), des plantages. Il faut compacter et ça repart.
Par contre parfois après cette opération, si je contrôle les tables, les tables principales perdent leur index et en conséquence les liens entre table sautent. Si je ne le vois pas tout de suite je retrouve des tables avec des enregistrements défectueux ####### et des doublons, pas simple de remettre les liens par la suite.
Avez-vous déjà constaté ce problème, et surtout quelle peut-en être la cause (je pense à des liaisons réseau défectueuses). Sachant que chez certains clients je n’ai aucun soucis depuis 10 ans….
Une autre cause pourrait être le conflit lors de la génération de la clé primaire par numéro auto. D’après un forum il semblerait que si deux utilisateurs demandent un nouveau numéro en même temps Access perde les pédales ?
J’utilise le code suivant pour créér un enregistrement, xmateriel une variable qui contient le nom de la machine. Un nouveau numéro de clé (numéro Auto) Rs![NUMERO] est défini par access, existe-t-il un façon de vérifier que le nouveau numéro est libre avant update : RefreshRecord, utiliser dmax et affecter avec le code le nouveau numéro dans un champ non Auto ?

Code :

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

1
2
3
4
5
6
7
 
Set Rs = db.OpenRecordset("HISTORIQUE", dbOpenDynaset)
         With Rs
        .AddNew
        ![MATERIEL] = xmateriel
         .Update
          End With

Merci de votre aide. Je sais qu’Access n’est pas une base bien adaptée à ce type d’exploitation, je n’ai pas le choix et la plupart du temps cela fonctionne très bien.

[nico84]

Bonjour,

Il faut compacter et ça repart.

De mon coté j'ai constaté qu'à partir d'une taille compactée de l'ordre de 50Mo un compactage quotidien est obligatoire, sinon la taille de la base diverge rapidement et ça plante
Ensuite au-delà de 100Mo je passe à MSQL
On est donc très loin du 2Go maxi théorique

[jmareal]

Merci Nico, mais j'ai trouvé un client avec une bases de 80 Mo, si le temps d'accès était déplorable, le compactage a rendu en effet la base exploitable.
Par contre la table principale n'avait aucun soucis et cela malgré 9 ans d'exploitation... avec des compactage très rares .... donc mon problème vient d'autre chose....

[nico84]

base de 80 Mo

AVANT compactage ?

la table principale n'avait aucun soucis et cela malgré 9 ans d'exploitation

En 9 ans elle n'a fait que grossir...

Si c'est toujours sur les mêmes postes, la qualité de leur connexion réseau est aussi une piste. En particulier le gigabit est quasi indispensable mais bon c'est rare de ne pas l'avoir aujourd'hui