OK. Here goes …
I saw that there were a few hits on google about this “problem”
including the peculiar bindaddress workaround but I wasn’t entirely
convinced. So I started poking around with the source code and
looking at the latest releases thinking that if this was a problem
before, then it would probably have been solved by now. In the
process discovered that:
(i) This really is a fast moving project. Release cycle seems to
average a week or two!
(ii) We are using v1.1.119 in DHIS2. Current version is v1.2.132.
(iii) there are issues of version compatibility with the h2 file format.
So thinking that this could be the problem (my external h2 client was
1.1.114) I decided to update my dhis2 and local client to the latest
and greatest v1.2.132. To my great disappointment (my dhis-web
compile is very slow) this made no difference at all other than a more
helpful exception being thrown and reported on. So …
Well sometimes I am stupid and sometimes I am very stupid
My url in hibernate.properties is:
Then in my client (h2 console or openoffice jdbc) I used:
and of course it doesn’t connect. The dhis2 connection opens the file
in embedded mode which means other clients can’t do the same thing
(file locking prevents this). Other clients have to connect using
tcp to get access in server mode. So if instead I use:
everything works like a charm! My guess is I’m not the only one who
was doing this. And I doubt if this has much to do with my h2 version
upgrade. Knut, try using a tcp url like this with your setup and see
if it works. If so problem soved.
There is of course a downside. If I configure this url in openoffice
(my preferred way of accessing h2 db) I can only open it if h2 is
running in server mode (eg my dhis2-live is running) which is a bit of
a pain. I need to actually have two db connections configured - one
for server mode and one to open the db directly. But I guess you
can’t have your cake and eat it.
Final thought on version upgrade. It is very tempting to look at
bumping up our h2 version in dhis2 with one big pro and one big con.
The con being that there will likely be incompatibility with existing
h2 file format (not a major issue as I don’t think there’s much h2
production use but it might mess with our sample db). The pro being
that each new release seems be improving postgres compatibility. If
we can freely exchange db dumps between h2 and postgres that would be
more than cool. Given that exchange between postgres versions is
troublesome anyway I’m not holding my breath too much, but its worth