Discussion :

[alakauf]

Bonjour,
Je suis en train d'essayer de faire une application qui doit accéder à une base MySQL par ODBC. Le driver ODBC est celui fourni par Oracle en version 5.01.11.00. Mes accès marchent plus ou moins. En effet j'ai régulièrement l'erreur:
[Microsoft][Gestionnaire de pilotes ODBC] Longueur de chaîne ou de mémoire tampon non valide
Et je ne sais pas comment faire pour m'en débarrasser afin que mon application fonctionne correctement.

[Népomucène]

Il faut nous fournir le code + stacktrace

accéder à une base MySQL par ODBC

alors là, je suis perplexe : pourquoi utiliser ODBC (qui n'est plus utilisé que pour accéder à Access et encore !)
plutôt que le bon driver JDBC qui marche sans peur et sans reproche ?

[alakauf]

C'était une demande de mon "client". Son but étant de pouvoir configurer directement sa connexion sans "entrer" dans le code de l'application, donc sans nécessité d'avoir un fichier de configuration définissant l'IP de la base, le nom utilisateur et le mot de passe.

[Népomucène]

Ouaip il définit lui-même le contenu du fichier DSN.

Mais de toutes façons, avec un DSN, il doit tout de même définir les paramètres de connexion.

[alakauf]

Tout à fait. Mais avec ODBC les infos de connexion sont extérieures à l'application. Tout ce que connait l'application c'est un nom de connexion ODBC.

[Népomucène]

Ben quelle est la différence avec un fichier de configuration lui aussi extérieur à l'application ?
Perso c'est ce que j'utilise tout le temps.

[alakauf]

C'est la solution que je suis en train de pousser. Il y a néanmoins une différence non négligeable. Le fichier externe est visible de tout le monde. L'accès ODBC est réservé aux administrateurs système.

[Népomucène]

un bon petit cryptage du fichier de paramètres ...

[tchize_]

un petit rappel important me semble à mettre ici.

C'est écrit en noir sur blanc sur le site d'oracle/sun depuis près de 10 ans


Le driver n'est pas supporté, il n'est pas recommandé et est fournis comme élément transitionnel pour les databases ne fournissant pas d'autre driver.
De plus il est extrèmement peu performant.

Pour ton message d'erreur, la seule chose qui me viens à l'esprit: est-ce que tu n'ouvrirais pas un connexion ODBC dans un thread pour ensuite l'utiliser dans un autres? Ce n'est pas supporté par jdbc ce genre de chose.


Quand au mot de passe -> quand l'admin encode les informations sur le DSN dans les boites ODBC, le mot de passe est aussi stocké sur le disque, faut pas croire. Maintenant si ça peux les rassurer, ça ne manque pas les solutions pour crypter des fchiers de configuration mais .... faudra fournir le mot de passe de décryptage quelque part