Discussion :

[ypicot]

Bonjour

J'ai un bug assez bizarre sur une appli.
De manière tout à fait classique, j'ai une table dans une base "data" sur un serveur, partagée (liée) par plusieurs utilisateurq.
Lors d'ajout plus ou moins simultanés dans cette table l'appli plante aléatoirement avec un message "format de base de données non reconnu" ou "Access a détecté que cette base de données est incohérente et va essayer de la récupérer". Lorsqu'on essaie de rouvrir la base, on se retrouve avec un msg similaire, problème qui se résout neuf fois sur dix grâce à un simple compactage/réparation de la base data (et dans le dixième cas, par une restauration du backup de la nuit, avec les pertes de données que cela entraîne).

Les enregs dans cette table ne sont pas créés un par un par l'utilisateur, mais par un script qui insère plusieurs enregs à la suite.

Après avoir éliminé plusieurs possibilités, une solution envisagée serait que la clé primaire, un classique NumeroAuto incrémenté, soit dans les choux.

D'où ma question : le NuméroAuto est-il généré par le client (ce qui pourrait expliquer un conflit, le serveur n'étant ni proche ni rapide) ou directement par le .accdb partagé ?

Merci par avance,

Yvan

[marot_r]

Bonjour.

Access n'est pas client/serveur, tout le travaille se fait sur le poste qui exécute l'application.
La base sur le serveur est un simple fichier partagé.

Je soupçonne un problème de réseau, genre micro coupure.

Aussi j'ai eu des problèmes avec une version 64 bits de Access qui "bousillait" ma BD en réseau. Une fois la BD copiée en locale les problèmes ont disparu.

A+

[ypicot]

Effectivement, Access est un serveur de fichier notamment pour les requêtes (qui sont toutes traitées en local), mais je me posais la question pour les NumeroAuto (qui est intégré à la table).

Le problème me semble trop fréquent pour une micro-coupure. De plus, le message s'affiche sur un poste (pas toujours le même), alors que l'autre ou les autres continuent de tourner. Ceci dit, une fois la corruption détectée, il faut tout déconnecter, compacter/réparer (ou récupérer le backup) et tout redémarrer.

Quand tu dis "bdd copiée en local", cela signifie que la bdd n'est plus partagée ?
A titre indicatif, j'ai mis en local tout ce qui pouvait l'être, seules les tables vivantes sont partagées.

Yvan

[marot_r]

Le calcul se fait sur le poste client qui demande le nouvel enregistrement.

En gros c'est :

1. Hé tout le monde j'ai besoin d'un nouveau numéro, ne toucher à rien.
2. Bon là je calcule mon numéro dans mon coin.
3. J'enregistre mon numéro dans la table.
4. Hé, tous ! C'est fait. La table est dispo.

Ma solution ne nécessitait pas de partage donc la copie en locale était la solution la plus simple.
Il semblait qu'il y avait une incompatibilité avec l'OS du serveur et Access 64 bits.
Et la solution de M$ était : Utiliser la version 32 bits.

A+

[ypicot]

Donc en gros, ce serait la gestion des verrous qui serait foireuse, et qui provoquerai cette corruption d'index (et donc de fichier du coup).

Le poste client est en 32 bits, je vais vérifier si le serveur est en 32 ou 64.
Le cas échéant, je ferai un test en générant moi-même la clé primaire.

Merci pour la confirmation : le numéro auto est bien généré sur le client.

Yvan

[marot_r]

Le problème que j'ai rencontré n'était que avec Office 64 bit.
Si tu as une version 32 bits, tu ne devrais pas être concerné.
Est-ce que tu as beaucoup d'utilisateurs ?

Et c'est peut-être du a un effet de cache, quoi que je n'ai jamais expérimenté un tel problème.
Il est possible que le calcul soit fait en "local" et envoyé au serveur avec un délais.
Si cela se produit sur 2 machines en même temps cela pourrait corrompre ton fichier.
Je n'au aucune idée de comment valider mon hypothèse, désolé :-(.

A+

[marot_r]

Aussi vérifie que les verrouillages sont bien à "L'enregistrement en cours".
À priori cela ne devrait pas avoir d'influence, au pire tu perdrais des données mais ta BD resterai fonctionnelle.

Bonne chasse au bug.

A+