Hibernate Dialect error against Firebird 2.1.2 DB via ODBC

Report · Sep 22, 2009

Dev environment: CF9, CF Builder 1

I have successfully installed CF9 and, following along in the excellent training videos, I was able to connect my first CFBuilder project (in design mode) to Firebird using an ODBC connection. The "validation query" works ok from the Administrator. The data source appears in the RDS View right alongside the cfartgallery, cfbookclub etc., and I'm able to work with it, see the fields, drag & drop etc.

....however...

When I try to run the completed page that is supposed to pull back data into my browser view... I get the error message:

org.hibernate.HibernateException: Hibernate Dialect must be explicitly set for database: Firebird

-What file/setting do I have to edit to tell Hibernate the dialect setting that it's looking for? (The Dialect 3 was already established in the ODBC connection definition)

-Why is hibernate intefering during run time, when CF9, and CFB1 were able to connect and extract all table and field attributes for the RDS view?

Thanks in advance.

Report · Sep 23, 2009

I think you're better off trying to find some JDBC drivers for Firebird. CF & Hibernate are both Java apps, and will expect to use JDBC for connectivity. Using ODBC on Java is a bit of a hack.

CF does not have built-in support for Firebird for its Hibernate integration (supported DBs listed here: http://help.adobe.com/en_US/ColdFusion/9.0/Developing/WSED380324-6CBE-47cb-9E5E-26B66ACA9E81.html), so you'll need to configure it manually (how? Don't know, but look @ the Hibernate website: https://www.hibernate.org/80.html, and the CF9 docs).

As to why you're seeing discrepancies between JDBC, RDS and Hibernate... they're three different systems. Making A DSN just requires a JDBC connection, and basically passes the SQL statements through the driver to the DB. I have no idea how RDS works, but it's probably just doing something with JDBC as well. Hibernate is a vastly complex application that sits on top of JDBC, and needs to generate an awful lot of very DB-platform specific code. So it needs to know exactly what DB its talking to. Simply "JDBC" is not sufficient.

--

Adam