Discussion :

[nuke_y]

Hum, t'as quoi comme SGBD ?

EDIT :
SQLServer non ?

RE-EDIT :
Je confirme que sous SQLServer on a pas accés à cette fonction

[nuke_y]

Bon reprenons à 0, est-ce qu'il est IMPENSABLE qu'un utilisateur possède un fichier texte contenant la liste de ses villes séparées par un ";" et qu'à chaque rapport, il prenne l'objet Ville, le mette dans les conditions, lui ajoute un opérateur "Dans liste", Créé une liste de valeurs nommée "Liste des Villes" et quand il rafraichi, copie colle la liste des villes dans l'invite de commande "Liste des Villes" ?

[bolderiz]

Oui c'est une solution qui marche et que j'ai essayé en m'inspirant de ce que tu m'as dit sur les objets personnels, je la garde sous le coude mais elle est encore un peu trop complexe (il faut d'abord créer une condition dans un document puis
visualiser, puis exporter les lignes par copier-coller dans un tableur pour faire la concaténation).

PS : je fais mes tests en ODBC-Access, mais bon ca doit être comme sqlserver

Un développement complémentaire ne me fait pas peur, le niveau d'ergonomie semble être un facteur très important pour les utilisateurs.

Merci encore pour ton aide

[nuke_y]

Oui alors le passage "Visualiser" n'est pas nécessaire.

Effectivement, tu risques d'avoir du mal d'éviter la partie "Ajout d'une condition" + "copier-coller de la liste"

Sinon... hmmm j'ai ptet une idée avec les filtres.

Tu peux utiliser des filtres qui permettent de filtrer les données APRES les avoir ramenées. Donc ça sera aussi long pour voir les données d'une ville ou de 100, mais l'utilisateur ne verra apparaître que les villes qu'il souhaite.

Tu peux créer des filtres avec des macros Excel qui iront lire dans un fichier Excel à côté (par exemple).

Sinon tu peux aussi imaginer d'autres solutions du même genre avec un fichier excel qui contient la liste des villes à considérer.

Evidemment on parle dans ce cas là de tableaux de bord près à l'emploi, il ne faut pas que l'utilisateur touche un peu trop le contenu du tableau.