IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

ADO.NET Discussion :

DataSet "localisé" (multilinguisme) : comment faire ?


Sujet :

ADO.NET

  1. #1
    Membre du Club
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2004
    Messages
    50
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Août 2004
    Messages : 50
    Points : 46
    Points
    46
    Par défaut DataSet "localisé" (multilinguisme) : comment faire ?
    Bonjour à toutes et à tous.

    Voila, je suis face à un problème de langues avec mon application. En effet, je dois gérer du multilinguisme au niveau de mon DataSet.

    J'ai fait quelques recherches à ce sujet et j'ai vu qu'il y avait une propriété "Locale" au niveau du DataSet. Je pensais que cela aurait le même effet que la propriété Locale d'une Form (avoir dans ce cas autant de jeux SQL qu'il y a de langues) mais visiblement, cela n'a de l'effet que pour par exemple comparer des variables numériques dans la langues choisies (symbole décimale).

    Donc, je me tourne actuellement vers une autre solution un peu moins élégante en voulant passer un paramètre "langue" à la méthode Fill de mon TableAdapter, mais je rencontre des problèmes à mettre cela en oeuvre.

    La requête que j'utilise n'interroge pas directement une table, mais construit directement une liste de valeurs. Mais j'aurais de toute façon le même problème avec une requête sur une table.

    Voici un exemple de requête (j'utilise une base de données Oracle et les langues à gérer sont le français et l'allemand) :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    SELECT 1 AS ID_TYPE, CASE WHEN :lang = 'de' THEN 'Type1_DE' ELSE 'Type1_FR' END AS LABEL
    FROM DUAL
    UNION
    SELECT 2 AS ID_TYPE, CASE WHEN :lang = 'de' THEN 'Type2_DE' ELSE 'Type2_FR' END AS LABEL
    FROM DUAL
    ORDER BY ID_TYPE
    Lorsque je crée un TableAdapter avec cette requête, il me génère une méthode Fill sans paramètres, mais il y a pourtant bien un paramètre "lang" dans cette requête. Du coup, j'ajoute moi-même ce paramètre manuellement dans le designer du DataSet, mais à l'exécution il ne tient pas compte de mon paramètre. Ma méthode Fill a bien désormais un paramètre, mais on dirait que le mapping entre le paramètre de la fonction et le paramètre de la requête ne se fait pas.

    J'ai pensé que c'était parce que j'utilisais un même paramètre plusieurs fois dans ma requête, donc j'ai remplacé "lang" par "lang1" et "lang2" :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    SELECT 1 AS ID_TYPE, CASE WHEN :lang1 = 'de' THEN 'Type1_DE' ELSE 'Type1_FR' END AS LABEL
    FROM DUAL
    UNION
    SELECT 2 AS ID_TYPE, CASE WHEN :lang2 = 'de' THEN 'Type2_DE' ELSE 'Type2_FR' END AS LABEL
    FROM DUAL
    ORDER BY ID_TYPE
    Mais cela ne change rien non plus, et le designer ne génère pas lui-même les paramètres. Du coup je les ajoute à la main mais là c'est pareil, on dirait que le mapping entre la fonction et la requête ne se fait pas...
    J'obtiens l'erreur "ORA-01008: toutes les variables ne sont pas liées", et à un moment j'avais aussi ROW-00001, un problème de mémoire ? :-s

    Je vais continuer à chercher de mon côté, mais si des âmes charitables pouvaient m'aider à élucider ce problème, ce serait super sympa :-)

  2. #2
    Membre du Club
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2004
    Messages
    50
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Août 2004
    Messages : 50
    Points : 46
    Points
    46
    Par défaut
    Rebonjour,

    J'ai progressé sur mon problème.

    Déjà, pour que la méthode Fill/GetData soit générée avec des paramètres, il faut apparemment que lesdits paramètres se trouvent dans la clause WHERE de la requête et pas ailleurs.
    Ensuite, il est préférable de nommer distinctement chaque paramètre, même si on les voit comme un seul.
    C'est en tout cas le cas quand on interroge une base de données Oracle, le comportement est peut-être différent avec un autre type de base de données.

    Voici un nouvel exemple de requête par rapport à l'exemple que j'ai laissé avant :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    SELECT 1 AS ID_TYPE, 'Type1_FR' AS LABEL
    FROM DUAL
    WHERE :lang1 = 'fr'
    UNION
    SELECT 1 AS ID_TYPE, 'Type1_DE' AS LABEL
    FROM DUAL
    WHERE :lang2 = 'de'
    UNION
    SELECT 2 AS ID_TYPE, 'Type2_FR' AS LABEL
    FROM DUAL
    WHERE :lang3 = 'fr'
    UNION
    SELECT 2 AS ID_TYPE, 'Type2_DE' AS LABEL
    FROM DUAL
    WHERE :lang4 = 'de'
    ORDER BY ID_TYPE
    Du coup, l'appel de la fonction ressemble à ceci :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    myTableAdapter.Fill(myDataTable, "fr", "fr", "fr", "fr")
    ... ou ceci :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    myTableAdapter.Fill(myDataTable, "de", "de", "de", "de")
    Je suis pas très fier de ce code que je trouve bof bof, mais honnêtement je n'ai pas trouvé d'autre solution pour l'instant.
    Si, je pourrais très bien faire un Fill de tout, puis seulement après appliquer un filtre sur ma DataTable par exemple, mais je préfèrerais pouvoir le faire directement dans la requête car je n'aime pas rappatrier des données inutiles. L'exemple ici retourne très peu de données, mais je pourrais avoir beaucoup plus de lignes.

    Si d'autres personnes peuvent proposer des solutions "plus propres", elles sont les bienvenues

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo