I have published this info on the internet and you can view them at http://www.kengsi.com/jdbcwiz.html. Hope this will help few others by having this information in one single place. I will add more databases as time goes on so if you don't see information about a database driver you are interested in, please do let me know.
Showing posts with label jdbc. Show all posts
Showing posts with label jdbc. Show all posts
Tuesday, February 7, 2012
JDBC Driver Class Names and URL Formats For Popular Databases
A recurring pain for me is digging up JDBC driver class names and URL formats when ever I need to connect to a database over JDBC. So I thought I will document driver / URL details plus additional info such as Spring DBCP configuration, Tomcat datasource configuration and connection validation SQL information for all popular databases.
I have published this info on the internet and you can view them at http://www.kengsi.com/jdbcwiz.html. Hope this will help few others by having this information in one single place. I will add more databases as time goes on so if you don't see information about a database driver you are interested in, please do let me know.
I have published this info on the internet and you can view them at http://www.kengsi.com/jdbcwiz.html. Hope this will help few others by having this information in one single place. I will add more databases as time goes on so if you don't see information about a database driver you are interested in, please do let me know.
Don' forget to click the +1 button below if this post was helpful.
Wednesday, November 16, 2011
Why Developers Shouldn't Be Using JDBC Connections, Statements and PreparedStatements
I cringe in pain every time I come across a project that's still using JDBC API interfaces / classes like Connection, Statement, PreparedStatement. Most of them are not legacy projects either.
I truly believe in this day and age you shouldn't be working directly with these low level interfaces and the associated boiler plate code you eventually end up writing. Basically you will have to get the connection, create statements or prepared statements, get the result set and once you are done close everything in a finally clause. This will not only create long, ugly and hard to read code but will make it very easy to introduce errors by say forgetting to close a connection.
So if you are not building a toy Java application you should really be using a high level API that automatically handles these tasks for you. I am not a very big fan of fancy ORM libraries and my preferred data access library has been Spring JDBC for the last two years or so. It gives you the full power of raw SQLs while making it easy do what you want to do with minimum coding. End result is simple, readable and most importantly maintainable and less error prone data access code.
Once you have configured Spring JDBC, an update or a select can be done in one line of code.
So if you are still using low level JDBC code in your applications, its time to consider moving to something like Spring JDBC. You can move your code gradually to the new APIs as Spring JDBC can and will coexist with low level JDBC code.
Take a look at the Spring documentation to get a more in depth idea of all available features of Spring JDBC
I truly believe in this day and age you shouldn't be working directly with these low level interfaces and the associated boiler plate code you eventually end up writing. Basically you will have to get the connection, create statements or prepared statements, get the result set and once you are done close everything in a finally clause. This will not only create long, ugly and hard to read code but will make it very easy to introduce errors by say forgetting to close a connection.
So if you are not building a toy Java application you should really be using a high level API that automatically handles these tasks for you. I am not a very big fan of fancy ORM libraries and my preferred data access library has been Spring JDBC for the last two years or so. It gives you the full power of raw SQLs while making it easy do what you want to do with minimum coding. End result is simple, readable and most importantly maintainable and less error prone data access code.
Once you have configured Spring JDBC, an update or a select can be done in one line of code.
So if you are still using low level JDBC code in your applications, its time to consider moving to something like Spring JDBC. You can move your code gradually to the new APIs as Spring JDBC can and will coexist with low level JDBC code.
Take a look at the Spring documentation to get a more in depth idea of all available features of Spring JDBC
Don' forget to click the +1 button below if this post was helpful.
Tuesday, June 12, 2007
Why would anyone want to buy a commercial JDBC driver?
In all the projects that I worked on over the last 5 to 6 years, nobody even thought about using a commercial JDBC driver. When I started on J2EE development you had to buy a JDBC driver for MS SQL server. This was around 2000-2001 when Microsoft didn't have an implementation.
We bought a driver from i-net software (Opta if I remember correctly) which I guess was the best commercial driver available at that time. Later on the application was ported to Oracle and we were happy to use the Oracle thin driver instead of bothering to buy another commercial implementation.
Since then I have worked for several big enterprise clients, developing Java web applications that connected to Oracle, MS SQL Server and DB2 (ver 7.2) databases. All these applications were using the database vendor provided drivers and all was well except for the DB2 driver (net driver).
I used to visit i-net software web site frequently as their Crystal Clear reporting tool was used in some earlier projects. Today I stumbled upon their site again after a long time and I started wondering why no one even considers using commercial drivers anymore including myself.
I could think up of a few possible reasons to shell out few bucks for a JDBC driver.
1. Performance
2. Reliability
3. Available features (JDBC 3.0, XA support etc...)
Now if we take Oracle thin driver and the above list, I don't see how a third party driver can provide significant performance and reliability over the thin driver.
As for features, thin driver has every thing you would need on an average project. Commercial implementations usually have few additional bells and whistles (e.g. i-net Opta driver supports SSL encryption and implements JDBC 4.0 API) which usually are not that important.
I guess same could be said for the SQL Server drivers from Microsoft and hopefully the new DB2 drivers from IBM, that is they does the job for your average project.
Also given the fact that application servers like BEA Weblogic includes its own drivers for all major databases including SQL Server, DB2, Sybase and Informix, I really don't see a reason to buy a JDBC driver from a third party.
Having said that, I would love to know about instances where a commercial driver was used and the reasons behind it.
P.S. Elaborating on the issue with the older DB2 driver:
DB2 v7.2 didn't come with a type 4 JDBC driver and we had to use what was called the net driver. There was this funny problem where it failed to see some records in a table. Select queries would not return these records when connected through the net driver. We never figured out why and only solution was to delete the record and insert them back. Luckily for us it only happened in the QA server :). Anyhoo the database was upgraded to DB2 version 8 and the driver to the type 4 version that came with it.
We bought a driver from i-net software (Opta if I remember correctly) which I guess was the best commercial driver available at that time. Later on the application was ported to Oracle and we were happy to use the Oracle thin driver instead of bothering to buy another commercial implementation.
Since then I have worked for several big enterprise clients, developing Java web applications that connected to Oracle, MS SQL Server and DB2 (ver 7.2) databases. All these applications were using the database vendor provided drivers and all was well except for the DB2 driver (net driver).
I used to visit i-net software web site frequently as their Crystal Clear reporting tool was used in some earlier projects. Today I stumbled upon their site again after a long time and I started wondering why no one even considers using commercial drivers anymore including myself.
I could think up of a few possible reasons to shell out few bucks for a JDBC driver.
1. Performance
2. Reliability
3. Available features (JDBC 3.0, XA support etc...)
Now if we take Oracle thin driver and the above list, I don't see how a third party driver can provide significant performance and reliability over the thin driver.
As for features, thin driver has every thing you would need on an average project. Commercial implementations usually have few additional bells and whistles (e.g. i-net Opta driver supports SSL encryption and implements JDBC 4.0 API) which usually are not that important.
I guess same could be said for the SQL Server drivers from Microsoft and hopefully the new DB2 drivers from IBM, that is they does the job for your average project.
Also given the fact that application servers like BEA Weblogic includes its own drivers for all major databases including SQL Server, DB2, Sybase and Informix, I really don't see a reason to buy a JDBC driver from a third party.
Having said that, I would love to know about instances where a commercial driver was used and the reasons behind it.
P.S. Elaborating on the issue with the older DB2 driver:
DB2 v7.2 didn't come with a type 4 JDBC driver and we had to use what was called the net driver. There was this funny problem where it failed to see some records in a table. Select queries would not return these records when connected through the net driver. We never figured out why and only solution was to delete the record and insert them back. Luckily for us it only happened in the QA server :). Anyhoo the database was upgraded to DB2 version 8 and the driver to the type 4 version that came with it.
Don' forget to click the +1 button below if this post was helpful.
Subscribe to:
Posts (Atom)
