Bug 218800
| Summary: | HSQLDB doesn't yet support named parameters (":link_from_brand") | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Brian Johnson <bjohnson> |
| Component: | hsqldb | Assignee: | Deepak Bhole <dbhole> |
| Status: | CLOSED ERRATA | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 6 | CC: | caolanm, dbhole, robert.l.blake |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | hsqldb-1.8.0.7-2jpp.1 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2007-01-26 17:26:47 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Did you report this upstream (http://qa.openoffice.org/issue_handling/pre_submission.html), this is a little out of my expertise, and you'll likely get a quicker resolution. If you do, mention the upstream issue id here. 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 http://dba.openoffice.org/servlets/ReadMsg?list=users&msgNo=4190 a) Latest stable version of hsqldb: 1.8.0.7 so rawhide should be bumped to this b) perhaps a backport of this named parameters feature to the FC-6 hsqldb is indicated here. Is there a work around for this while waiting for corrected hsqldb rpm (if that is what will fix it)? It currently appears impossible to use subforms with native oo.org db files in FC6. 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! caolanm->dbhole: FYI re the request to get jpackage bumped to the 1.8.0.7 hsqldb release. hsqldb-1.8.0.7-2jpp.1 has been pushed for fc6, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report. |
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.