Discussion :

[Miouc]

Bonjour à tou.te.s,

Je suis nouvelle ici, et je n'ai pas trouvé la réponse à ma question dans une autre discussion, malgré mes recherches.

Je travaille dans la recherche et je crée des bases de données pour pouvoir consulter facilement nos stocks d'échantillons ou de réactifs divers et variés. Ce sont des bases de données simples, sans macro ou vba. Par exemple, je vais avoir une table avec la liste de mes protéines, une seconde table avec la liste des anticorps et une 3ème table avec les applications de ces anticorps.
La finalité est d'avoir un formulaire où je sélectionne ma protéine + 1 sous-form où je remplis les différents anticorps pour dirigés contre cette protéine + 2è sous-form pour lister toutes les applications de chaque référence d'anticorps.

Mon pbl est que, depuis peu, quand je veux sélectionner une table dans le form wizard (je travaille sur la version anglaise de microsoft 365 business), cela fait tout planter. ça ne le fait pas avec toutes les tables mais je n'ai pas trop réussi à identifier le point commun de celles qui plantent, et cela se produit dans plusieurs bases différentes.
La difficulté complémentaire est que nous avons un service info externe qui gère le côté serveur etc... et qui fait que je ne suis pas admin de mon PC.
J'ai déjà essayé de voir avec eux et de leur donner les pistes trouvées ici et là mais rien ne marche. Ils ont essayé le classique mettre à jour office, le pc, désactiver l'antivirus, réparation de la base etc...

Ils me disent que ma table n'est peut-être pas optimisée, dans le sens pas assez splitée. Il est vrai que dans la base sur laquelle ils testent, les 2 tables qui font planter sont celles avec le + de colonnes: 17. Mais il s'agit bien de 17 attributs différents d'un seul de mes anticorps donc je ne peux pas y faire grand chose.

Pensez-vous que le nombre de champs pourrait être la cause ?
Auriez-vous d'autres pistes ?

Merci bcp
Une apprentie geek désespérée.

[Belga16]

17 colonnes, ce n'est pas énorme.
Pouvez-vous poster copie compressée de la BD (zip, rar, ..), avec des données fictives ?

[Miouc]

17 colonnes, ce n'est pas énorme.
Pouvez-vous poster copie compressée de la BD (zip, rar, ..), avec des données fictives ?

Bonjour,
Oui, bien sûr, voilà.

J'ai été voir une base de données faite par une collègue, on a effectivement des tables plus grandes que cela. La sienne ne plante pas du tout. J'ai remarqué qu'elle avait bcp moins usé du "enforce referential integrity", alors que moi je force pas mal de choix déroulant avec des cascade update/delete à chaque fois pour avoir un truc carré. Est-ce que cela pourrait venir de là ?
Car cela me le fait aussi sur une autre database que je viens de faire aussi mais qui est bien + petite

Merci bcp

[Miouc]

Je vous mets quand même aussi le zip de la 2ème, bcp plus petite mais avec les mêmes pbl.
Quand ça plante ça me crée un fichier .laccdb avec un petit cadenas, comme si elle était utilisée, et ça ne s'en va jms si je ne le supprime pas. Je ne sais pas si ça peut aider.

[Belga16]

J'ai ouvert la 2è BD, mais n'étant pas spécialiste dans votre domaine, je n'arrive pas à reproduire l'erreur.
Pouvez-vous décrire les étapes (actions à entreprendre) pour déclencher l'erreur ?

[Mat.M]

Quand ça plante ça me crée un fichier .laccdb avec un petit cadenas, comme si elle était utilisée.

je n'ai pas Access sous la main regarder s'il est possible d'ouvrir la base en mode exclusif.
Il me semble qu'il y a cette option
Sinon ça vient peut-être du dossier qui n'a pas tous les droits (lecture,écriture..)

[Miouc]

Il suffit de faire create/form wizard
Et c'est là en sélectionnant les tables que ça plante, mais pas avec toutes. Dans la 2ème base celle qui plante le plus est primer pair. Et dans la 1ère c'est primary antibody

[Mat.M]

Il suffit de faire create/form wizard

oui mais lorsque je parle d'ouvrir la base en mode exclusif c'est faire fichier >> ouvrir un fichier lorsqu'aucune base n'est ouverte.
Ou alors le problème c'est que le fichier access a des liens sur une autre base.

[Belga16]

J'ai pu créer un formulaire via le wizard dans la 2ème base avec la table primer pair, sans aucun problème

[micniv]

Je peux aussi créer des formulaires sans aucun problème dans la 2éme base. (Access 2010)

Une première remarque serait de renommer plusieurs colonnes :
Eviter les caractères spéciaux ' ( / % ... car cela est fortement déconseillé dans la plupart des BD.
Eviter aussi l'espace que vous pouvez , si besoin, remplacer par _
Ainsi :
Primer pair name peut être renommé PrimerPairName ou bien Primer_pair_name
Tm (°C) " " Tm_celsius
% GC " " GC_perCent ....etc

Personnellement, j'évite d'utiliser les colonnes multivaluées [T_primer pair].Species car c'est un gadget relativement nouveau d'Access qui n'est pas standard dans les autres BD relationnelles.

[Miouc]

Bonjour,

Alors j'ai procédé par étapes:
- changer tous les noms potentiellement à pbl uniquement : ne résout pas le pbl
- éliminer les champs multivalues uniquement, sans changer les noms : ça a l'air de résoudre le pbl !

Un grand merci. Mais il me reste quand même des questions:
- pourquoi le pbl n'apparait pas chez vous ? (microsoft 365 ainsi que mon PC ont leur mises à jour de faites)
- je dois avoir plusieurs valeurs dans ces qq champs problématiques, j'avais crée une liste déroulante avec choix multiple pour "forcer" les gens à écrire chaque valeur tjs de la même façon afin de pouvoir potentiellement filtrer. Du coup, si je ne peux plus utiliser ça, j'imagine que je n'ai pas d'autre choix que de mettre un simple champ texte où les gens écriront librement ? (le but d'utiliser access étant de ne pas dupliquer les lignes pour chacune des valeurs du champ multivalue)

Merci

[argyronet]

Bonjour,

Cela peut provenir des dépendances des objets qui constituent votre base.
beaucoup de meli-mélo entre chacun d'eux.

Sur la table "T_Secondary Antibodies", il y a un message d'erreur si vous passez de View à Design.
Un fois les dépendances affiches, l'erreur disparaît.

Remarque, éviter de placer des clause SQL au sein des tables au niveau de la propriété Contenu d'un champ.
Il est de loin préférable de monter une requête dynamique dans le formulaire car d'un point de vue maintenance, c'est non seulement ingérable mais aussi peu conventionnel.

Argy

[Miouc]

Bonjour argyronet,

Merci pour vos réponses,si vous aviez toutefois le temps de détailler cela m'éclairerait bcp. Par exemple auriez-vous arrangé les tables autrement, c'est dans les relations qu'il y a du meli-melo ? Je me suis pourtant efforcée de faire au + simple.

Je n'ai jms eu de message d'erreur sur la table que vous citez.

De même, j'aurais aimé des précisions quant à votre dernière remarque, de quelles clauses parlez-vous ? à part des listes déroulantes et un champ où je "force" les majuscules, je ne vois pas de quoi vous parlez, je suis novice.

Merci !

[argyronet]

Bonjour,

Par exemple auriez-vous arrangé les tables autrement, c'est dans les relations qu'il y a du meli-melo

Jetez un œil aux dépendances des objets ; cela vous amènera à mieux cerner.
En fait votre application est effectivement instable ; j'ai voulu faire un copier/coller d'une clause SQL (dernier paragraphe de ce message) et j'ai eu une sorte de freeze ; j'ai été obligé de quitter l'application.

Je n'ai jms eu de message d'erreur sur la table que vous citez.

Je n'ai pas réussi à le reproduire non plus... Bizarre.

De même, j'aurais aimé des précisions quant à votre dernière remarque, de quelles clauses parlez-vous ?
Merci !

Exemple :
Table : T_Secondary Antibodies
Champ : Targeted isotype
Contenu : SELECT [L_Isotype].[Isotype] FROM L_Isotype ORDER BY [Isotype];

Il vaut mieux que la clause WHERE soit construite soit dynamiquement soit statiquement dans le formulaire dans la propriété de la zone de liste déroulante que dans la table.
Une table doit rester un objet qui ne contient que des données et leur type et leurs clauses de restriction au niveau des champs.

Argy

[Miouc]

Bonjour,

Je sais qu'il y a bcp de dépendances entre les tables, mais j'ai besoin de toutes ces dépendances.
En fait, le but est d'avoir à taper manuellement le moins de choses possibles, déjà pour que ça soit + facile à remplir, mais surtout pour avoir une base propre. Par exemple, les noms de fournisseurs, nous en avons un qui s'appelle fisher scientific, certains vont écrire fisher, ou fischer ou fisher sci etc... Je veux bloquer les choix pour que tout le monde écrive de la même façon, pour qu'on puisse ensuite facilement faire des tris ou rechercher des infos.

Du coup je crée une liste déroulante dans la table pour ça, soit en créant une table qui me sert de liste (quand on a bcp de choix, pour qu'un fournisseur soit facilement ajouté), soit, si les choix sont très réduits, j'indique les options possibles à la main dans les propriétés du champ.

Du coup je me retrouve avec des tables qui sont en fait des listes, et je relie tous les champs que je veux bloquer dans ma table d'intérêt à ces listes.

Ce que vous me dites c'est qu'il vaudrait mieux que je fasse cette étape au niveau du champ dans le formulaire seulement, pas au niveau des tables ?

[loufab]

Bonjour,

Vu le comportement constaté par Argy, un bon coup de decomp/comp ne serait pas inutile.

Scinder l'application serait également plus sûr. Une application professionnelle en exploitation doit répondre à certains critères pour éviter des catastrophes.

Cordialement,

[argyronet]

Ce que vous me dites c'est qu'il vaudrait mieux que je fasse cette étape au niveau du champ dans le formulaire seulement, pas au niveau des tables ?

Oui, c'est au niveau client (ce que l'on appelle front-end) que l'on sollicite les tables filles pour alimenter les listes des tables parentes (avec l'ID comme champ de colonne liée).

Cela minimise les dépendances ; j'ignore si le plantage de l'assistant en est causé par cela mais au pire, ne les utilisez pas.
Au bout du compte, avec le recul, vous vous apercevrez que monter manuellement un formulaire et ses contrôles va plus vite et surtout, vous en avez la maîtrise.

Et en //, comme le souligne Fabrice, un petiot décompactage serait opportun.

Argy

[Miouc]

D'accord, merci à tous.