Discussion :

[AndréPe]

Bonjour,
Access2000, WXP
Dans une table se trouvent les éléments permettant de dimensionner des variables au démarrage du projet.
Cette table contient les noms des bases et les noms des tables de chaque base attachées à l'application, et peut être modifiée par l'utilisateur en ajoutant ou en retirant une ou plusieurs bases ou tables

On peut donc au démarrage
- en déduire le nombre N de bases utilisées,
- dimensionner la var NomBase(N) qui contiendra les noms de ces bases et la var NbTab(N) qui contiendra le nombre de tables rattachées de chaque base
- extraire de la table les valeurs de NomBase(n) et NbTab(n)
- dimensionner la var NomTab(N,M) où M est le maximum de NbTab(N)
- et pour terminer, extraire de la table les NomTab(n,m)

Je souhaiterais pouvoir déclarer toutes ces variables 'public' mais ça ne peut pas se faire dans une procédure.

Les déclarer d'emblée comme public exige de connaître le nombre de bases et de tables en cause, ce qui n'est pas possible.
On peut évidemment prendre des nombres suffisamment élevés, mais c'es gâcher de l'espace.
J'ai bien entendu une idée du nb maxi de bases qui pourraient être utilisées, ainsi que du nb max de tables .
C'est ce que je fais avec respectivement 10 et 9, et dans une procédure, je fait comme indiqué ci-dessus, à cela près que je n'ai plus besoin de dimmensionner ces variables, ni de trouver N et M.

Mais si une autre solution existe, je suis preneur.

Merci de votre attention.
Amitiés

[Heureux-oli]

Il est possible de les déclarer en public et de leur attribuer une valeur ensuite.
Il n'y a que pour les constantes que ce n'est pas possible.

[random]

Ben je vois pas bien pourquoi il y a besoin de variables
Si tu as une table contenant le nom des bases et des tables utilisées tu disposes d’une structure d’accés à tes données la manipulation d’un recordset en dao sera plus facile que l’accès à des variables dont le nombre est inconnu.
Tu disposes toutefois, si tu tiens à ta solution de deux structures permettant l’accès à un nombre variable d’éléments : la collection, et l’array() utilisé avec un redim preserve.
Si tu choisis la collection en mettant le nom de la base en clef tu peux mettre le chemin en item, inverser chemin=clef, et nom de base=item., voire gérer une double collection.
Mais dans tous les cas les informations contenues dans tes variables seront strictement égales à celles de ta table accessibles en sql ou en dao. Ta solution se justifierait s’il s’agissait de données critiques, placées en mémoire vive, et adressables sans calcul pour optimiser des traitements lourds.

[AndréPe]

Heureux-oli écrit :

Il est possible de les déclarer en public et de leur attribuer une valeur ensuite.
Il n'y a que pour les constantes que ce n'est pas possible.

C'est ce que je fais, mais pour pouvoir déclarer des array, il faut connaître leur nombre.

random écrit :

Ben je vois pas bien pourquoi il y a besoin de variables

En cours de traiement les valeurs de ces variables peuvent changer si on ajoute ou retire une table, des constantes ne le permettraient pas.

et aussi

Si tu as une table contenant le nom des bases et des tables utilisées tu disposes d’une structure d’accés à tes données la manipulation d’un recordset en dao sera plus facile que l’accès à des variables dont le nombre est inconnu

D'accord, mais lorsqu'il faut dans une boucle passer en revue les tables d'une base donnée, c'est moins rapide et plus lourd que des variables immédiatement disponibles

l’array() utilisé avec un redim preserve

Mais cela préserve-t-il aussi l'étendue ?
Je vais voir.

En ce qui concerne la suite, laissez-moi le temps de digèrer vos suggestions !
Merci
Amitiés

[AndréPe]

Citation:
l’array() utilisé avec un redim preserve

Mais cela préserve-t-il aussi l'étendue ?
Je vais voir.

J'ai vu : le redim provoque une erreur : "Array déjà dimensionné"
Je ne sais donc pas si ça préserve l'étendue !

J'en suis au même point.
Je cherche tjrs.