Description of problem:
Version-Release number of selected component (if applicable):
openoffice.org-core-2.0.4-5.5.3
openoffice.org-base-2.0.4-5.5.3
hsqldb-1.8.0.4-4jpp.1
How reproducible:
always
Steps to Reproduce:
1. make 2 tables in oo.org base using a native database file
2. create a relationship between 2 fields in the tables
3. use the form wizard to make a form with a subform (for the other table)
Actual results:
Gives an error related to the oo.org created subform SQL about the colon (":")
in ":link_to_table2"
Expected results:
Should work without errors
Additional info:
oo.org base uses named parameters (ie variables) to link the table data for the
subform to the table data for the main form.
This version doesn't recognize that it is a named parameter.

I've been working with the openoffice dba mailing list.
Not sure if I totally understand the technicallities
It sounds as though the issue is fixed in new versions of hsqldb
Also, sounds like new versions of oo.org base auto-compensate for older versions
of hsqldb

I had exactly the same problem. I downloaded the 1.8.0.7 release of HSQLDB from
sourceforge, extracted the jar files from the lib directory of the zip into my
home, and added those JARs to the classpath within OOo (Tools -> Options ->
Openoffice.Org General -> Java -> Classpath -> Add Archive). My subform is now
working fine, though slowly. Maybe I just have unreasonable expectations for speed?
Anyway, this is a workaround that seems to work at first glance. Which probably
means it will hose my data as soon as I turn my back, though that's not so
important to me at this precise moment. That said, if this were fixed perhaps
by an official update to FC6 HSQLDB it would:
(a) make me very happy
(b) perhaps allow me to use one of these things for a client. They have a
mailing list in Excel and some donation information, which is as far as I can
tell a textbook 1-to-many relationship. But they need simple and transferable,
which an embedded DB would be. I'd like to be able to offer this as on option,
since the many-tables-in-Excel strategy has been a disaster for them already,
but I'm reluctant (to say the least) until this is worked out.
Thank you!