Discussion :

[olra72]

Bonjour,

J'avais développé un formulaire dont un des contrôles était une liste déroulante, la source résultant d'une requête. Tout marchait normalement !

Le logiciel évoluant, j'ai changé la dite requête.

Mais je travaille sur une version de développement (accdb) pendant que les utilisateurs tournent sur une version de production (accde). Lorsque je fais une "mise en production", je pars d'une matrice accdb vide, je réimporte les tables depuis l'accde, puis les formulaires, les requêtes, les états et les modules depuis l'accdb. Ensuite, j'enregistre le résultat en accde - qui devient la nouvelle version de production - alors que l'accdb devient ma nouvelle version de développement.

Ce qui se passait d'étrange, c'est que l'accde ressuscitait toujours les anciennes versions des requêtes ... sauf si, juste avant d'enregistrer l'accde, j'allais voir les dites requêtes (elles ont toujours été telles que je m'attendais à les trouver) et sortais avec un "Enregistrer".

Après avoir tout essayé, la seule solution que j'ai trouvé a été de changer définitivement le nom du contrôle (le copier sous un autre nom, effacer le premier et renommer la copie comme précédemment remettais le bug en place).

Tout se passe donc comme si, associé à un nom de contrôle, il y avait une sorte d'historique ineffaçable, qui ne ressort qu'en certaines occasions et qui, comme un état quantique, se modifie dès qu'on va le regarder de près.

Est-ce que ça dit quelque chose à quelqu'un ?

Cordialement,

[titi95]

Bonjour

Quand on importe un objet qui porte le même nom que l'existant, le nouveau est automatiquement renommé (Nom + numéro d'incrémentation)
Il faut préalablement à l'importation, soit supprimer les anciennes versions des objets concernés, soit pour être plus prudent les renommer (personnellement c'est ce que je fais en mettant des XXX en début de nom pour les repérer facilement plus tard)
Les nouvelles versions importées portent le BON nom et sont ainsi directement utilisables par la base.
As-tu malgré cela un souci ?

Titi95

[olra72]

..je pars d'une matrice accdb vide ..

... donc ce n'est pas un problème de nom existant (ou je n'ai pas compris ta remarque). D'ailleurs, je n'importe pas des contrôles individuels mais des formulaires tout entiers, et ça a très bien marché pendant longtemps.

Il me vient une idée : sur les contrôles de liste déroulantes qui ont posé problème, je suis AUSSI passé d'une requête écrite en ligne à une requête explicite (càd de "Propriété / Données / Contenu / SELECT * FROM ..." à "Propriété / Données / Contenu / <nom d'une requête existant comme objet dans le volet de navigation>").

Serait-il possible que, lors de l'import des requêtes (qui mentionnent des contrôles situés dans les formulaires) puis des formulaires (qui utilisent ces requêtes), ACCESS rencontre un sorte de problème de précédence et ressuscite d'anciennes versions "en ligne" qui auraient subsistées quelque part ?

Cordialement,

[titi95]

J'avais bien compris, mais ton problème ressemble beaucoup à ce que je t'expliquais :

Quand on importe un objet qui porte le même nom que l'existant, le nouveau est automatiquement renommé

ce qui fait que c'est l'ancienne version qui est appelée.
Or, tu nous dis que tout marchait bien jusqu'à... un certain moment. Comme si des versions étaient restées cette fois-ci, et donc les nouvelles étaient présentes mais renommées.

je suis AUSSI passé d'une requête écrite en ligne à une requête explicite

Il est vrai que la syntaxe n'est pas la même. ???
Si les objets et les contrôles ne sont pas renommés, et qu'ils sont bien nommés dans la requête, il y a toujours concordance. Sauf si un a changé ? Comme une Zone de liste ?
Je ne vois pas l'impact de l'import.

Reprend ta requête et vérifie que les noms d'objets, contrôles, champs... existent bien.

J'avoue ne pas avoir plus d'idées.

Titi95

[olra72]

Je viens de passer un moment à essayer de reproduire le problème sur un mini-base (y compris les transitions accdb/accde, les réimports et la transformation d'une requête in-line en objet). Rien à faire : Sur un mini fichier, ça marche impec !

Bon ! Il est vrai que ma "vraie" appli fait 10 Mo, contient 80 tables, 150 requêtes et des masses de contrôles qui, d'un formulaire à l'autre, portent souvent le même nom. Certains de mes formulaires ont des onglets, certains onglets contiennent des sous-formulaires et je suis en mode formulaires multiples, donc je peux avoir dix formulaires ouverts en même temps.

En tout cas, s'il y a un vrai bug quelque part, il n'est pas trivial à mettre en évidence. Je vais voir si j'ai un éclair dans les jours qui viennent ...

Soyons positif : si ça se reproduit, je sais déjà qu'il suffit de renommer le contrôle pour faire disparaître le problème !

Merci à tous,

[titi95]

Bon courage !

N’oublie pas de cliquer sur Résolu si tu en restes là aujourd'hui.

Titi95

[Ric500]

Bonjour olra72,

Une suggestion à prendre pour ce qu'elle vaut: as-tu pensé à faire apparaître les objets système (MSysQueries, MSysObjects) et à vérifier d'une version à l'autre la colonne ObjectID?

Bon courage!

[loufab]

Bonjour,

Ce qui me choque dans ta manip c'est ceci :

Lorsque je fais une "mise en production", je pars d'une matrice accdb vide, je réimporte les tables depuis l'accde, puis les formulaires, les requêtes, les états et les modules depuis l'accdb. Ensuite, j'enregistre le résultat en accde

Si les tables sont toujours les mêmes (récupérées de la version prod) pourquoi sont-elles inclues dans l'accd IHM ?
Autant les isoler dans un accdb (ou e - ça ne changera rien) à part et faire une attache.
Tu t'affranchis de cette manip lourde et casse gueule.

L'architecture "client" / "serveur" est beaucoup plus souple pour la mise en production.

Lorsque tu livres, une fois le stade compilation/tests/validation passé, tu n'as plus qu'à faire un decomp/comp puis généré un accde et livré l'ihm.

PS : ton appli fonctionne en partagée ?

Cordialement,

[olra72]

Salut Loufab,

Oui, oui, il y a entre trois et dix personnes dessus à tout moment. Au début, j'avais utilisé le partitionnement mais les performances étaient minables (effet du réseau d'ici ?). En plus, la chef du labo voulait pouvoir partir avec la base le weekend et la ramener le lundi suivant ... ce qui excluait d'entrée l'approche client-serveur. Pour des raisons de sécurité, le réseau du site est totalement fermé aux accès externes. Heureusement que la base ne contient rien de sensible sinon, ces aller-retours seraient ... euh ... douteux ?

Ah oui, je suis passé en accde parce les versions d'Office sont différentes selon les postes et que, sur une version accdb, les références VBA sont automatiquement upgradées (même par un non-administrateur) dès lors qu'un utilisateur est le seul à se connecter. Et, une fois les références upgradées, les utilisateurs qui avaient les postes plus anciens ne pouvaient plus se connecter. Amusant n'est-ce pas ? Avec la version accde, ce phénomène disparaît !

Cordialement,

[loufab]

Bonjour,

C'est normal qu'en accde tous ne puissent y accéder. Cela vient du fonctionnement d'ACCESS.

En Accde les références ne sont pas actualisé, si la version d'ACCESS n'est pas strictement iso à celle de dev l'ouverture est impossible. Dans ce cas un accde par version ou un accdb est la solution.

Concernant les perfos en pseudo "client/serveur" :
Cela ne dépend pas QUE de l'infra, il y a beaucoup de chose qui rentre en ligne de compte. Notamment la profondeur du chemin au fichier bdd. (cf mon tuto sur les perfos)
Quant à prendre l'appli chez soit (haaa ces chefs !), effectivement, à moins d'utiliser une attache automatique et de copier la bdd, le plus simple est un fichier unique.
Attention cependant à cette facilité, en cas de vautrage d'un client ce n'est pas simplement l'ihm qui est en vrac mais l'ensemble... données comprises.

Cordialement,