Issue 80338 - openoffice base cannot connect to database with system-hsqldb
Summary: openoffice base cannot connect to database with system-hsqldb
Alias: None
Product: Base
Classification: Application
Component: code (show other issues)
Version: 680m217
Hardware: All All
: P2 Trivial (vote)
Target Milestone: OOo 2.3
Assignee: tml
QA Contact: issues@dba
Keywords: oooqa, regression
Depends on:
Blocks: 80294
  Show dependency tree
Reported: 2007-08-04 04:21 UTC by ht990332
Modified: 2007-09-01 15:39 UTC (History)
12 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

HSQLDB_JAR (1.22 KB, patch)
2007-08-08 10:03 UTC, ocke.janssen
no flags Details | Diff
adapt configure check to require >= (1.16 KB, text/plain)
2007-08-09 01:04 UTC, rene
no flags Details
patch for connectivity/source/drivers/hsqldb (1.42 KB, patch)
2007-08-10 09:04 UTC, ocke.janssen
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description ht990332 2007-08-04 04:21:01 UTC
under m224, if you create a database file and enable using the wizard for
tables, you get a cannot connect to database error.

The connection to the data source "New Database" could not be established. 

General error: java.lang.NullPointerException

This has been broken since at least m217 and is a regression from openoffice 2.2.1
Comment 1 Mechtilde 2007-08-04 07:38:35 UTC
Which OS do you use?
If you use Linux, which distribution?

Where do you get Is it a distribution version?

Please answer _all_ questions.

Comment 2 ht990332 2007-08-04 08:18:41 UTC
Linux / ArchLinux.
No, it's not a distribution build. It's a home build using system hsqldb (same
one used in 2.2.1).
Comment 3 Mechtilde 2007-08-04 08:51:04 UTC
I add Rene as CC

We both discuss this problem yesterday.
Comment 4 rene 2007-08-04 10:27:13 UTC
confirmed. Already in m222, too.

More infos:
- happens also with internal hsqldb
- happens on gcj and ecj builds, and even with IBM JDK 1.4, too (There's no Sun
for ppc). Regardless of the build, on runtime it doesn't work with *any* JDK
(tried on i386 using gij, Sun 5, Some OpenJDK 7 b, and gij, IBM 1.4 on ppc)
- happens on both ppc and i386 (the archs I tested so far)
- on the console it prints out ClasssNotFoundException
- the jar accessed before this is juh.jar, which *is* there, but maybe something
inside javaunohelper broke,.

(my theory from yesterday didn't hold yet, need to try again with a fresh
build/install, info added here it it proved)

Setting target to 2.3, as this must be fixed for 2.3...

This is more than P3, Base is unusable with this.
Comment 5 rene 2007-08-04 10:28:36 UTC
reassign to someone sensible (not dbaneedsconfirm)
Comment 6 rene 2007-08-04 10:34:09 UTC
msc: This is the issue you so unfriendly rushed away with "Base works. Point".
Obviously I am neither the only person having this and ht990332 is building
vanillla, OOo, so..

Adding you to Cc
Comment 7 rene 2007-08-05 11:09:48 UTC
Ccing sb/kr, as this seems to be a jvmfwk/javaunohelper-Problem.

As juh seems to be involved, I checked my Java settings and came to jvmfwk3rc:

This is my current one:

$ cat /usr/lib/openoffice/program/jvmfwk3rc
UNO_JAVA_JFW_CLASSPATH_URLS= file:///usr/share/java/bsh.jar
file:///usr/share/java/hsqldb.jar file:///usr/share/java/xercesImpl.jar
file:///usr/share/java/xalan2.jar file:///usr/share/java/serializer.jar
file:///usr/share/java/mysql.jar file:///usr/share/java/sapdbc.jar

which worked fine so far. The last three entries are added manually by me
for adding the JDBC MySQL/PoistgreSQL and SAP DB Drivers to the classpath when
installed. The other ones are added directly by the build when you use
those Java libs from external (--with-system-bsh, --with-system-hsqldb).

I tried around a bit and noticed that when removing the bsh, hsqldb, mysql,
postgresql and sapdbc entries it works (I have a hsqldb.jar symlink in classes/,
too, otherwise it'd not find hsqldb.jar - which is the whole purpose of adding
this entry).

Now let's look at those files in detail; 

1 mysql.jar, postgresql.jar and sapdbc.jar are not existing on the fs because 
  not installed. This was working on 2.2.1, though, and this makes sense when
  you want to pre-register them so they get in effect if someoone just installs  
  one of those drivers without the driver package having to fiddle with OOos 
  "private" configs

2 bsh.jar and hsqldb.jar are symlinks:
  $ ls -l /usr/share/java/bsh.jar /usr/share/java/hsqldb.jar
lrwxrwxrwx 1 root root 13 2007-08-03 18:21 /usr/share/java/bsh.jar -> bsh-2.0b4.jar
lrwxrwxrwx 1 root root 18 2007-08-03 18:21 /usr/share/java/hsqldb.jar ->

3  xercesImpl.jar, xalan2.jar, serializer.jar are "normal" jar files of xalan 
   and xerces:

$ ls -l /usr/share/java/xalan2.jar /usr/share/java/xercesImpl.jar
-rw-r--r-- 1 root root  194508 2007-07-16 15:41 /usr/share/java/serializer.jar
-rw-r--r-- 1 root root 3199127 2007-07-16 15:41 /usr/share/java/xalan2.jar
-rw-r--r-- 1 root root 1230728 2007-07-03 20:22 /usr/share/java/xercesImpl.jar

Now, as said, when removing the non-existing files and the symlinked files there
it magically works (given that bsh.jar and hsqldb.jar also exist as symlinks in
classes, which appears to still work).

"OK, no non-existing files or symlinks" then I thought and removed the
non-existing files from there and changed those entries to reference the "real" jar.
-> Still failed. I can't explain this given that it works with real jars in
xalan etc., Maybe because of the additional dots?

OK, then my last try was to change it back to hsqldb.jar and bsh.jar but copy
the real jars to there, replacing those symlinks.
-> intrestingly, still fails. although xalan etc. work!

It only works for me, If I remove the entries from jvfmfwk. The xalan/xerces
ones can stay there, but the bsh/hsqldb need to go to make it work for me...
Comment 8 Frank Schönheit 2007-08-05 13:35:48 UTC
cc'ing jl, too - he's the master of the JVM config stuff, IIRC. Also adding oj.

asssigning to SB. Stephan, there's two reasons for this: 1) you're probably much
faster than me in finding out what happens here 2) I'm on vacation currently,
will be without any internet access starting soon, and the issue sounds pressing
enough with target 2.3.

The only thing I tried to far is installing an ordinary developer snapshot 224
on one of our usual developer machines, and there the problem did not occur.

fs->rene: The class not found error you talked about - is there a mention of the
class which has not been found (I suppose you would have said so then, but ...)?
Comment 9 rene 2007-08-05 16:36:32 UTC
fs: exactly. it just prints out "ClassNotFoundException" on the console. Nothing
Comment 10 rene 2007-08-05 16:42:46 UTC
Comment 11 Frank Schönheit 2007-08-05 20:33:08 UTC
hmm, with system hsqldb .... if that's really the (only) difference ... rene,
could you please check whether reverting to revision 1.22 of
connectivity/source/drivers/hsqldb/HDriver.cxx solves the problem? If so (I
suppose it does), then we need to make the changes which happened in rev. 1.23
depend on !SYSTEM_HSQLDB. Stephan should be able to tell whether there are more
changes which need this dependency.
Comment 12 rene 2007-08-05 23:11:13 UTC
fs: no, fails also with 1.22
Comment 13 Stephan Bergmann 2007-08-06 10:45:09 UTC
How to reproduce with Sun-built SRC680m224

1  Add the following line to program/jvmfwk3rc (which should not yet have any
line starting with UNO_JAVA_JFW_CLASSPATH_URLS):


2  Start program/soffice, then "File - New - Database", in the first pane of
"Database Wizard" dialolg click "Next >>" and on the second pane check "Create
tables using the table wizard" and click "Finish".  In the "Save as" dialog
click "Save":  "ClassNotFoundException" on stdout and "The connection to the
data source could not be established." error box (clicking "OK" then gives the
" General error: java.lang.NullPointerException"
stack trace on stderr).

The problem is that in line 222 of

  Class zclass = Class.forName(fileaccess_class_name);

fileaccess_class_name is  The
application class loader that loaded Database.jar does not know that class.

Comment 14 ocke.janssen 2007-08-06 11:36:47 UTC
@sb: When you replace the line

everything works. It seems that this line overwrites existing jar files.
Comment 15 Stephan Bergmann 2007-08-06 12:04:35 UTC
@oj:  "It seems that this line overwrites existing jar files."  No, that line
specifies the JVM's classpath.  With a standard, Sun-built OOo, the JVM
classpath is empty (so the line is missing entirely).  With a build that is
configured --with-system-hsqldb, the JVM classpath contains hsqldb.jar (in some
system location), but not sdbc_hsqldb.jar.  However, with the current code, code
from hsqldb.jar tries to load a class from sdbc_hsqldb.jar with Class.forName. 
That only works if the code from hsqldb.jar has been loaded with a classloader
that is a (reflexive, transitive) child of a classloader able to load from
sdbc_hsqldb.jar.  The assumption that this works is broken when configuring OOo
--with-system-hsqldb: hsqldb.jar is loaded by the JVM's application classloader
(as it is on the classpath), whereas sdbc_hsqldb.jar is only known to some more
specific classloader that is a (transitive) child of the application
classloader.  So, the current code is broken.

I can think of several ways how to fix that:

1  In from above, instead of only passing a fileaccess_class_name
property, also pass information where that class can be found (e.g., a URL with
which an appropriate classloader can be created; caveat: that could result in
the StorageFileAccess class being loaded multiple times by different,
incompatible classloaders).

2  In from above, instead of Class.forName use
Thread.getContextClassLoader to load the class, and at some appropriate place
down the call stack set an appropriate context classloader.

3  As a quick hack, at scp2/source/ooo/profileitem_ooo.scp:1.49 l. 874--876 also
add (the OOo-local program/classes/...) sdbc_hsqldb.jar to
Comment 16 Stephan Bergmann 2007-08-06 12:15:48 UTC
[Suggestions 1 and 2 above would of course imply a fix to the hsqldb sources and
not OOo, and OOo's configure --with-system-hsqldb would need to be adapted to
require an appropriately recent system hsqldb.jar version (and the hsqldb
version included in the OOo sources would need to be updated as well).]
Comment 17 rene 2007-08-06 12:22:27 UTC
the fix should be self-contained in OOo imho. so if 1 and 2 need a patch for
hsqldb, I'd vote for 3...
Comment 18 ocke.janssen 2007-08-06 13:37:36 UTC
@rene It's not that easily possible to fix this issue without changing the
hsqldb sources. For 2.3 I vote for "removing SYSTEM_HSQLDB" from the configure
script. I just looked at the patch file for hsqldb and it's already really large
and many things won't be working as expected. And the horrible thing for me is
that someone will notice it too late and he may already have a data loss :-(
Comment 19 rene 2007-08-06 13:49:28 UTC
oj: ... except when you get your hsqldb package maintainer to add the bugfixes
from the OOo tree. (Which I am trying). But I simply doubt he will add stuff like
for 1 and 2.

If 3 works (as sb says, didn't try it yet), why not use this as a workaround?
Comment 20 Stephan Bergmann 2007-08-06 15:14:41 UTC
Suggestion 3 above turned out to not work: the wizard dialog to create tables
does not appear.  The reason seems to be that sdbc_hsqldb.jar has in its
META-INF/MANIFEST.MF Class-Path dependencies on jurt.jar and unoil.jar, and for
some reason (which is not obvious to me at the moment) it does not work to load
(part of) the Java UNO runtime with the application classloader instead of the
UnoClassLoader.  (That oj's direct modification of UNO_JAVA_JFW_CLASSPATH_URLS
seemed to work was pure coincidence; those URLs need to be separated by spaces
instead of semicolons.)
Comment 21 Stephan Bergmann 2007-08-06 15:54:00 UTC
"which is not obvious to me at the moment":  Obvious now, see issue 80383.
Comment 22 Frank Schönheit 2007-08-06 21:36:02 UTC
> I just looked at the patch file for hsqldb and it's already really large

All patches are part of HSQLDB-HEAD, i.e. will be in (which according to
Fred Toussi is nearly ready to be released, we planned to integrate it for
2.3.1). The only exception is a small build-related patch with 2 lines or so.

Also, the patch file can at any time easily be regenerated: All patches which we
currently apply to HSQL are in hsqldb/patches. hsqldb/patches/index.txt explains
which patches are applied why. Every new patch added should definitely be part
of the patches/* stuff, else it will get lost over time. On the other hand, if
it *is* part of the patches/* stuff, it probably won't get lost ...

In general, I think since 3 has been named a workaround, I am not sure I like
this or a similar option. We should strive for a complete solution which lasts a
while without breaking next month.

Ocke, can you discuss this with Fred? I am not sure I understand the caveat
Stephan mentioned for 1., and its possible consequences, so I don't have an
opinion whether I like 1. or 2. better ...
Comment 23 ocke.janssen 2007-08-07 08:58:45 UTC
@rene: I have to patch the hsqldb sources to fix this issue. As sb already
mentioned solution 3 doesn't work. 
So to make things work on your side you have to patch your system hsqldb. But
this only helps all OOo users which know the same maintainer. My personal
opinion is the SYSTEM_HSQLDB is currently not working as expected. It will work
when our patches get integrated into a hsqldb release. Frank mentioned release where we also have to include the patch for this issue of course to make
things work. Do you think that it would be possible to set the target to 2.4 due
to the fact that a patch of the hsqldb sources is necessary?
Comment 24 rene 2007-08-07 09:13:23 UTC
if hsqldb will fix it, yes. (Or I can persuade my hsqldb maintainer to
add the path himself to, depending on how long takes). But I do
have my workaround already anyway....

"But this only helps all OOo users which know the same maintainer."

... or use a release of a distro containing and OOo depending on that
version :). Nothing for users to care about in this case :)

We then of course need to change the configure check to check for the change, too.

But, assuming you have the patch already, I'd still vote for 2.3 for the reason
that the patch in the source is there then can be used as reference. (Or attach
it to this issue)

fs: When is release due? "nearly ready" is not that concrete for
plannig ;-)
Comment 25 ocke.janssen 2007-08-07 10:03:38 UTC
@rene: As others doesn't have such a friendly maintainer, I will fix the issue
in that way that I remove SYSTEM_HSQLDB from the configure script and we will
first reintegrate it when we have a version of hsqldb which includes all patches
we need. Otherwise I have no possibility to figure out if the patch I need
exists. Which of course would lead to an installation set which doesn't work.
Comment 26 rene 2007-08-07 10:10:34 UTC
oj: uh, no. please don't.

system-hsqldb works when you have hsqldb.jar in classes and apply the workaround.
system-hsqldb will work when you do it with a newer hsqldb.
I still rely on it. I still use it (with the workaround to remove the
file://usr/share/java/hsqldb.jar etc. from jvmfwk3rc)

I agree that it's broken out of the box right now and that it needs fixed/worked
around currently, but that's *no* argument to remove the *complete* check from
configure. If your patch makes it into hsqldb, it will work again and we
can improve the check later to check for the right version.

Anyone else will find this issue and know what to do. system-hsqldb is mainly
used by packagers anyway, and they should know where to look (here). Users
normally don't build their OOo on their own and if they do they normally don't
use system-hsqldb. Exceptions prove the rule, but those people should be able to
find this issue, too (summary and description imho is clear enough to find it
via IZ).

Don't break distris packages which can work around it/don't break stuff which
magically will be fixed with a new hsqldb in whatever distro for this..
Comment 27 ocke.janssen 2007-08-07 11:28:35 UTC
@rene: But the problem still remains. Distros which use the patches for hsqldb
will create a installation which won't work out of the box. And
most users even know what issue zilla is. Later on we introduce the define
SYSTEM_HSQLDB again. When we know that all fixes we need are in a hsqldb
milestone we can check.
Comment 28 ht990332 2007-08-07 12:19:34 UTC
Why not just make the configure script check that system hsqldb is >=
Is hsqldb expected to be out before 2.3.0 official release? If so, it
should be safe to make the change from now, right?
Comment 29 Frank Schönheit 2007-08-07 12:46:32 UTC
> When is release due?

We (Fred and /me) talked about releasing it about 10 days ago, to hit the 2.3
timeline. Unfortunately, we did not have QA resources on OOo side anymore for a
full-blown QA cycle (though smaller cycles before suggested there wouldn't be
any problems), so we shifted this.

If nothing changed on HSQL side, Fred should be able to release
immediately (ideally with Ocke's patch included, of course). Ocke, can you
negotiate this with Fred?
Comment 30 ocke.janssen 2007-08-08 10:02:13 UTC
Could someone test this patch file. Thanks.
Comment 31 ocke.janssen 2007-08-08 10:03:02 UTC
Created attachment 47380 [details]
Comment 32 Stephan Bergmann 2007-08-08 10:11:39 UTC
Re the attached i80338.patch:

1 In HDriver.cxx, something like

  aConvertedProperties[nPos++].Value <<=
::rtl::OUString(RTL_CONSTASCII_USTRINGPARAM(HSQLDB_JAR "$ORIGIN/classes/sdbc_hsqldb.jar"));


  aConvertedProperties[nPos++].Value <<=

would probably be simpler.

2 Remember to remove the hsqldb.jar entry from
Comment 33 ocke.janssen 2007-08-08 10:43:31 UTC

Could anyone please modify the configure script in that way that the version
number must be >= 
I have no experience with that :-)
Comment 34 rene 2007-08-08 10:57:31 UTC
Hmm. the obvious place to check - MANIFEST.MF - only contains 1.8.0 in

Manifest-Version: 1.0
Ant-Version: Apache Ant 1.7.0
Created-By: 4.1.3 20070718 (prerelease) (Debian 4.1.2-14) (Free Softwa
 re Foundation, Inc.)
Specification-Title: HSQLDB
Specification-Version: 1.8.0
Specification-Vendor: The HSQLDB Development Group
Implementation-Title: Standard runtime
Implementation-Version: build-680m222(Build:9183)
Main-Class: org.hsqldb.util.SqlTool

So this is not helpful. For Debian, looking at the link target is helpful, but
that doesn't help for other distris:
$ ls -l /usr/share/java/hsqldb.jar
lrwxrwxrwx 1 root root 18 2007-08-08 10:46 /usr/share/java/hsqldb.jar ->

Maybe we should check for the patch present and not for the version?

For that, oj, I might need the patch for hsqldb itself, which you promised to
attach to this issue...
cmc: Do you have an idea how we can check this?
Comment 35 ocke.janssen 2007-08-08 11:43:20 UTC
@rene: There is no patch for hsqldb :-) I solved it inside OOo.
Comment 36 rene 2007-08-08 17:06:49 UTC
ah, ok. :)

oj: wrt the configure check... If you get hsqldb to change its MANIFEST.MF so it
has the full version ( instead of 1.8.0) we could look into that one. I
don't see an other general solution (the filename one is Debian-specific)
Comment 37 rene 2007-08-09 01:03:34 UTC
oj: if hsqldb did that, the attached patch would do it (+ running autoconf). Can
do that in dba23e after the new hsqldb is released.
Comment 38 rene 2007-08-09 01:04:43 UTC
Created attachment 47409 [details]
adapt configure check to require >=
Comment 39 ocke.janssen 2007-08-09 07:34:20 UTC
I just the okay from hsqldb. The new version n the manifest file will be Thanks and thanks for the dpatch file.
Comment 40 ocke.janssen 2007-08-10 06:46:52 UTC
I commit the configure script and one change in
connectivity/source/drivers/hsqldb/HDriver.cxx and

@rene: Could you please verify this. Thanks.
Comment 41 ht990332 2007-08-10 07:17:18 UTC
I tried the patch on
m225 with system hsqldb
It didn't fix it. I needed to make an additional change. 
I edited the installed jvmfwk3rc file and changed.

file:///usr/share/java/xml-apis.jar file:///usr/share/java/xercesImpl.jar
file:///usr/share/java/xalan.jar file:///usr/share/java/serializer.jar



replacing the spaces with semicolons. After that, openoffice base works fine.
Comment 42 Stephan Bergmann 2007-08-10 08:16:47 UTC
@ht990332:  As I said at #desc33, what is currently found at
(same as attached i80338.patch) is not enough.  Your "fix" of replacing spaces
with semicolons just happens to work for you, but does not fix the problem (see
getApplicationClassPath in jvmfwk/source/fwkbase.cxx:1.10 for how
Comment 43 rene 2007-08-10 08:52:58 UTC
oj: given that hsqldb is not out yet and the build now fails without it,
not necessarily ;-). But I can try whether the dba23e patch without the
configure check fixes the issue, yes... But not until tomorrow (my fast build
machine is down currently)
Comment 44 ocke.janssen 2007-08-10 09:03:38 UTC
@ht990332: Did you rebuild cconnectivity with the corrected To get
the correct patch please do cvs update -jCWS_SRC680_DBA23E_ANCHOR
-jcws_src680_dba23e in connectivity. But I also add the patch for it.
Comment 45 ocke.janssen 2007-08-10 09:04:39 UTC
Created attachment 47456 [details]
patch for connectivity/source/drivers/hsqldb
Comment 46 rene 2007-08-12 22:18:32 UTC
verified that a build with the changed connectivity and scp2 bits (and therefore
resulting in jvmfwk3rc without the hsqldb entry) works.

Not setting to verfied yet, though because the hsqldb ceheck part youldn't yet
been checked as hsqldb is not released yet.
Comment 47 ocke.janssen 2007-08-13 06:56:38 UTC
@rene: You could change the manifest by hand to test it. I don't exactly when
hsqldb version will be released and this issue should go into OOo 2.3 :-)

Comment 48 rene 2007-08-13 09:49:02 UTC
oj: this issue should *not* go into OOo 2.3 when it checks for a hsqldb not
available at the time OOo 2.3 is released (or when this dba23e gets integrated
into the master), sorry.

You wanted the check (I explained you that it's not stricly needed), now you
have to live with waiting for the check to actually work. And that is when
hsqldb is there. Of course, you can speed it up by getting them to
release, but...
Comment 49 rene 2007-08-13 10:45:43 UTC
oj: Hmm, the check currently is broken anyway...
Comment 50 ocke.janssen 2007-08-13 10:54:08 UTC
@rene: When this fix should be part of OOo 2.3, set the target correctly. As I
explained in IRC it is an error that SYSTEM_HSQLDB is defined without checking
for version No offical release of hsqldb so far included all patches we
apply. It doesn't matter if a person could apply the same patches, fact is there
exists no link on the hsqldb site where you can download this version and this
must be the case.
Comment 51 rene 2007-08-13 11:37:33 UTC
oj: and I didn't deny checking for hsqldb Just that it would be
immediately broken in the master when you check for something which doesn't even

As fs/you promised, hsqldb should be able to be released immediately. DO
that, and I've no hesitations to get this into 2.3.
If I thought we didn't need to check for this I wouldn't have (and still do,
because the current one is broken) invest time into this check. But I still
think that a configure script which checks for someting which is not there is
broken because the requirements cannot be fullfilled.

And the target is completely right: 2.3. You committed the configure check, not
me. I always thought of it being committed after we have to check someting for
(, and that means actually being available).

Easy solution for this: get hsqldb relased, as promised. Then we have a
check which is actually usable. Or get the configure check out of this cws and
do it in another cws (which the might not make 2.3, but the "not sufficient"
check is no regression in 2.3 anyway, it's already in earlier 2.x versions)
Comment 52 ocke.janssen 2007-08-13 11:59:32 UTC
For me there exists only two possible solutions.
1. Use a configure script which check for version (which of course can
not be full filled at the moment.)
2. Remove the SYSTEM_HSQLDB complete from the configure script and don't allow
building with a locally patched hsqldb version.

The argument with duplicate code doesn't work here as a download version of
hsqldb is currently and doesn't have the patches we need.

These are the only two valid solutions for this. And I thought that to check for
version is much better then totally remove SYSTEM_HSQLDB. When you use a
local hsqldb version it isn't that complicated to patch the manifest file in the
jar as well ;-) 
And I don't have a clue which date version will be released. It depends
on hsqldb.
Comment 53 rene 2007-08-13 12:02:43 UTC
(fixed configure check committed btw)
Comment 54 rene 2007-08-13 12:16:12 UTC
oj: I am fine with 1. As long as configures requirements can be fullfilled...
Wich it cannot. fs said that a hsqldb release should be able to be done fast, so
just do it, and we can forget about this issue.

But well, if "just" configure holds up the whole fix... :-( The fix has to be in
2.3, so...
But be prepared to get issues wrt that it's not buildable because it requires a
not-existing hsqldb version...

Yes, I can make the hsqldb maintainer change the manifest, too himself but that
would be a hack and simply lying about the version. 
Comment 55 rene 2007-08-15 14:51:48 UTC
oj: r10074 of
might be interesting:

"2007-08-14  Tor Lillqvist  <>

	* patches/src680/cws-dba23e.diff: It's not portable to use an
	#ifdef inside a macro argument."

According to tml it actually breaks the build on Windows, so reopening.
Comment 56 ocke.janssen 2007-08-16 06:34:59 UTC
Patch for windows compiler applied.
Comment 57 ocke.janssen 2007-08-16 06:35:56 UTC
Please verify. Thanks.
Comment 58 rene 2007-08-22 16:26:06 UTC
16:55 <@_rene_> tml_: ping?
16:55 <@_rene_> tml_: wrt dba23e again, will this one work with msvc?
16:55 -!- Irssi: Pasting 6 lines to #go-oo. Press Ctrl-K if you wish to do this
or Ctrl-C to
16:55 <@_rene_> +#ifdef SYSTEM_HSQLDB
16:55 <@_rene_> +IIIII"$ORIGIN/classes/sdbc_hsqldb.jar")
16:55 <@_rene_> +#else
16:55 <@_rene_>
16:55 <@_rene_> +IIIII"$ORIGIN/classes/sdbc_hsqldb.jar")
16:55 <@_rene_> +#endif
16:55 <@_rene_> that's what's currently in dba23e.
16:56 <@_rene_> -IIIIaConvertedProperties[nPos++].Value <<=
16:56 <@_rene_> +IIIIaConvertedProperties[nPos++].Value <<= ::rtl::OUString(
16:56 <@_rene_> oops, ^ was missing above the first paste
17:12 <@tml_> if it matches what's in ooo-build trunk, yes
17:12  * tml_ checks
17:13 <@tml_> seems so yes
Comment 59 Mechtilde 2007-09-01 09:09:56 UTC
@ ht990332

does it works now?

please comment
Comment 60 ht990332 2007-09-01 14:01:49 UTC
mechtilde, Yes it does work in OOG680_m2 with the patch, thanks.
Will this be included in 2.3 final?
Comment 61 Mechtilde 2007-09-01 15:39:33 UTC
this will be include in 2.3 final you can also test the RC1

-> closed