SQL FB 2.x et driver ODBC [Résolu]

[lrichard]

Bonjour,

Je suis confronté au problème suivant : je cherche à exploiter certaines évolutions du SQL propres à FB 2.0 (non dispo en 1.5.x) via ODBC. Or, par exemple, sur un statement de type "SELECT NEXT VALUE FOR mygenerator FROM RDB$DATABASE" qui passe bien sous ISql, j'obtiens en ODBC (avec le driver OdbcJdbc 2.00.00.144) l'erreur suivante :

[ODBC Firebird Driver][Firebird]Dynamic SQL Error
SQL error code = -104
Token unknown - line 1, char 13
VALUE

Le mot clé VALUE n'est donc pas apprécié. Ca m'embête car c'est la syntaxe recommandée et j'ai d'autres soucis en essayant d'exploiter SELECT GEN_ID(mygenerator, 1) FROM RDB$DATABASE (faut que je creuse...).
Par ailleurs, j'ai rencontré le même problème sur le mot clé LOCK dans un SELECT ... WITH LOCK.

Quelqu'un sait s'il y a une possibilité de faire accepter ce SQL au driver ? Y a-t-il d'autres drivers ODBC (gratuits) qui l'acceptent ?

Merci

[_skip]

Quel est votre langage de programmation?

[lrichard]

Envoyé par _skip

Quel est votre langage de programmation?

Merci de votre participation. On utilise un framework C++ (interne).
Selon moi, le problème est cependant indépendant de cela : C'est l'appel à l'API ODBC SQLPrepare qui renvoie cette erreur selon les ordres SQL qu'elle reçoit. La plupart des ordres passent très bien mais certains, faisant appel à des mots-clés particuliers, ne passent pas.
En plus des clauses WITH LOCK et NEXT VALUE, je viens de découvrir que la fonction CURRENT_TIMESTAMP ne passe pas non plus. A chaque fois, ça ne passe pas via le driver ODBC mais il n'y a aucun problème lorsque je teste le même ordre sous ISql.

J'imagine mal que le driver analyse lui-même le SQL passé. Il le transmet vraisemblablement au serveur qui effectue l'analyse. Mais peut-être que l'API FB (que je ne connais pas) permet de spécifier un niveau de dialecte et que le driver fournit une version correspondant à FB 1.5 ? J'émet cette hypothèse car j'ai vu une propriété DIALECT parmi les propriétés du driver ODBC FB qui prend une valeur de 1 à 3, 3 étant la valeur par défaut et correspondant a priori au dialecte le plus récent (et j'ai constaté en passant DIALECT à 1 que le driver était alors encore moins permissif).

[lrichard]

J'ai trouvé !

On peut préciser la dll client parmi les paramètres du driver ODBC. Par défaut, si ce n'est pas renseigné, je ne sais pas ce qu'il va chercher mais en spécifiant la FBCLIENT.DLL de mon client FB 2.0 (sous C:\program files\firebird\bin sous Windows), tout fonctionne et il comprend bien le SQL le plus récent comme je le désirais dès le départ.

[_skip]

J'ai demandé ça car je voyais pas bien pourquoi vous utilisez une sorte d'ODBC sur JDBC, je voudrais pas parler sans savoir mais ça me semble très indirect cette combine qui commence par du ODBC pour finalement passer par du JNI.

Si vous faites du C++, je pourrais vous recommander IBPP qui est une interface client en C++ excellente à la fois question performance et fonctionnalités.

[lrichard]

Je répond un peu tard à _skip, n'ayant vu sa dernière contribution qu'aujourd'hui:

Effectivement, passer par ODBC pour finalement faire du JDBC n'aurait pas beaucoup de sens mais ce n'est pas ce que nous faisons. JDBC n'apparaît dans mon message initial que dans le nom du driver et le framework interne C++ que nous utilisons s'appuie bien sur l'API ODBC.
C'est d'ailleurs aussi la raison pour laquelle on ne retiendra pas IBPP car on n'a très peu de choses à faire pour exploiter FB au niveau de notre framework actuel (il suffit de nous assurer que la grammaire SQL employée est compatible) alors qu'employer IBPP demanderait un développement plus conséquent. Les performances ODBC devraient être largement acceptables dans le cas qui nous concerne.
Merci encore de votre participation.