Discussion :

[Amstra]

Bonjour à tous,
J’ai une série de bug depuis quelques jours mais je n’arrive pas à identifier la cause.
J’ai fractionné une base (principale et frontale) utilisée en réseau par 5 postes.
La première semaine tout à bien marché et puis les bugs sont apparus sans raisons apparentes.

On a déjà travaillé en réseau avec une base Access et tout marchait bien ( le seul problème était quelques lenteurs sur le chargement des formulaires)

Aujourd’hui les problèmes sont les suivants :
• Certaines requêtes sont devenues inutilisables ( soit disant problème de mémoire temporaire) alors qu’elles fonctionnaient bien avant. Je les ai recréée et elles marchent à nouveau.
• Certaines données textes (du genre résumé d’un film )sont apparues sous forme de caractères chinois.
• La base principale se met en mode exclusif et interdit l’accès de toutes les frontales. En solution je copie la base et la recolle sur le serveur et ça résout le problème.


Voilà grosso modo la série de bug. Mais je n’arrive pas à trouver la ou les causes. Et le plus délicat est le passage de certains champs en caractères chinois.


J’ai plusieurs hypothèses :
• On est plusieurs à travailler sur un même formulaire et peut être qu’Access n’arrive pas à gérer les conflits d’écritures.
• J’ai compacté la base et il y a peut être eu un problème à ce moment là.
• Certains postes sont équipés avec Access 2000 et d’autres avec 2002.

merci de me faire part de vos suggestions ou expérience face à un problème similaire,
bonnes fêtes à tous
Amstra

[Domi2]

Bonjour,

Ce que j'essaierais dans un premier temps, c'est de réimporter tous les objets de la frontale dans une base neuve, et idem pour la base dorsale.

Si tu as des menus personnalisé, ne pas oublier de cocher l'option correspondante pour la dorsale, et ne pas oublier les relations lors de l'import des tables de la dorsale.

A faire sur des copies !

Domi2

[Amstra]

J'ai importé mes données dans deux nouvelles bases ( relations, macro, formulaires...). Le seul soucis c'est comment est ce que je fais pour importer le code ? les procédures événementielles ne marchent plus du coup !

[Invité]

Il faut égélement importer les modules s'il y en a.
Les codes des formulaires sont importés en même temps que l'importation des formulaires.
Ne pas oublier de remettre les références et recompiler.

[Amstra]

Bizarrement il m'a fallu trois tentatives pour que l'import du code se fasse correctement. J'ai donc ouvert une base vide puis clic droit et importer ( pour les tables, requêtes...) et les deux premières tentatives n'ont pas importer le code des formulaires! Au bout de la 3è tentative ça marche.
Par contre pour être sûr de faire les manip' correctement, comment on remet les références et comment fait on la compilation?

[Domi2]

Bonjour,

Quand la fenête de base de données est affichée, Alt+F11 pour ouvrir l'éditeur.

Pour les références, menu Outils ==> Références. Si tu en as qui sont marquées manquantes, tu peux en principe les décocher. Compare les références cochées avec ton application initiale pour avoir les mêmes.

Pour compiler, toujours dans l'éditeur, menu Débogage ==> Compiler (nom de ton projet). Une fois que cela compile sans erreur, tu compactes ta nouvelle base.

Il n'est pas sûr que ce genre de manipulation résolve ton problème. Mais le fait d'importer dans une base neuve "nettoie" en quelque sorte ton application (objets supprimés, par exemple, dont Access a gardé des traces). Elle va diminuer de taille.

Si cela n'améliore rien, ce sera une piste d'élimimée.

De toute façon, c'est une bonne habitude à prendre. C'est vite fait, et cela "pévient" les risques de corruption, surtout en phase de développement intensif.

Domi2

[Amstra]

Merci Domi pour cette précision et pour m'avoir donné la procédure à suivre. Je suis en congé pour quelques jours encore, et je ferai la manip dès mon retour.
Je reviendrai vers toi pour te tenir au courant.
On peut toujours rêver mais les quelques jours de repos de ma base access lui feront peut être du bien aussi!!!

[Amstra]

Bonjour,

Je vais procéder à la compilation cet après midi. Je vous mets en pièce jointe une capture d'écran du type de bug que je rencontre.
Je pense qu'il se produit après l'actualisation d'une requête mise à jour.
exemple: pour enregistrer une revue on rentre son n°, le titre 1 et le titre 2 dans une table 1 via un formulaire. Dans un deuxième formulaire on rentre le reste des éléments ( basé sur une table 2) (mois, année...). Pour ne pas ressaisir deux fois les éléments, dans le champ titre 1 et titre 2 de ce formulaire je lui demande d'aller me chercher les titres qui ont été saisies dans la table 1 (=[T_1]![Titre_1]), et ensuite j'actualise avec une requête mise à jour.

Peut être que c'est à ce moment là que se produit le "bug" ?
Je vous ai mis une photo du bug. En fonction de la version d'access utilisée on aura soit des caractères chinois, soit des petits carrés.
Merci

[Domi2]

Bonjour,

Une autre piste. Regarde cette discussion, puis celle donnée en lien à la fin.

A voir...

Domi2

[Amstra]

Bonjour Domi,

J'ai eu du mal à supprimer la ligne écrite en chinois car j'avais un message d'erreur 3709 qui me bloquait. Même en supprimant les relations entre tables... bref après quelques manip ( vérification de tous mes index) j'ai réussi à le supprimer et j'en ai profité pour compacter, réimporter, compiler, recompacter ma base ! Je croise les doigts car aucun bug depuis 15 jours!

Merci pour le lien, je n'avais pas vu ces discussions lors de mes recherches. Il semblerait que cela pourrait bien être le même problème que je rencontre ( import massif depuis excel, et copier coller de texte sur internet). Par contre je ne connais pas bien Nz, je sais à quoi ça sert mais pas bien l'utiliser! d'autant plus que dans ma requête ajout je n'ai pas de champ vide à importer mes deux champs contiennent systématiquement des données. Bref comment je fais pour savoir quel champ pourrait être le responsable et où poser mon NZ ( mon formulaire est basé sur une table et pas sur une requête, dans le doute j'ai créé une requête pour corriger ça)