Say you're working on an enterprise class system. Developers work on Windows
and Linux. Servers run Linux. Not so unusual.
Now enter Sybase SQL
Anywhere. Aka Sybase ASA or iAnywhere.
First off there are 2 different JDBC drivers. JConnect
(jconn3) and the iAnywhere JDBC driver (jodbc). It turns out that only the
iAnwhere driver actually works with the high availability option (although not
documented).
Also it turns out that the iAnywhere driver is really an ODBC bridge and you
have to specify another driver in the JDBC URL.
While a little confusing at first due to the lack of documentation eventually
you can dig up an example.
jdbc:ianywhere:driver=SQL Anywhere
10;dbn=mydatabase;eng=myserver;
Everything works and you move on with life.
Except that eventually you want to deploy your new code to the server.
BAM nothing works. All sorts of errors about no suitable driver
found.
After thrashing around for a few days you discover that the JDBC URL must be
different on Linux! (this
is the only page on the Internet that specifies this).
jdbc:ianywhere:driver=libdbodbc10.so;dbn=mydatabase;eng=myserver;
Of course your application now works on Linux, but not on Windows.
Now if I were writing my own code that needed to talk to the database there
wouldn't be much problem as I can use one of several techniques for figuring out
which driver I should be using.
However, this URL used to configure some enterprise reporting tool which uses
that same URL whether doing local report development or running from the
server.
So now I have 3 options.
- Install the reporting server on every developers workstation.
- Stand up a Windows version of the reporting server.
- Create ODBC DSNs on all affected systems.
While option #1 is enticing (I like developers to have a local copy of all
dependencies if at all feasible). Feasibility plays into the picture here
because of license costs.
Option #2 is certainly doable, but I am not a big fan of adding the overhead
of administering another server and keeping it in sync with all the others.
Options #3 is simple and works well. However, DSNs represent another thing
that needs to be set up on every developer and qa system. This also breaks my
rule of being able to check out the source tree and go, even on a new computer
(for reasons of continuous integration and easy new team member set up).
Ultimately we will go with #3 because it is low cost in dollars, and low cost
in time (we'll write an Ant target to do
the DSN setup).
Now wasn't that easy? It only took 3 days to work through in real time.