I can save the query if I don't try to use the Query Design View.
However, once I do so, I cannot edit it from the UI anymore. I instead
have to edit the
registry/instance/org/openoffice/Office/DataAccess.xml directy.

This really should be fixed!!

please have a look on it

unfortunately he's right, i tried it with a final and a current 
version: in both GPF. 

i took: select * from biblio where Type = '1' AND (Identifier 
= 'SAU99' OR Identifier = 'BOR99A')
AND (Address = 'Haar' OR Address = 'Bonn')

CLU: crashes only in this combination 

Hi,

will be fixed in the version.

Ocke

Hi,
will be fixed in the next or one later available version.

Best regards,
Ocke

Please don't change this to RESOLVED FIXED until it is fixed! I can't
track it under "My Issues" if it's closed, and I want to keep this
open until it is actually fixed.

Thanks!

Luigi,

but this is how Issuzilla is expected to work! According to
http://www.openoffice.org/issues/bug_status.html, FIXED means "A fix
for this issue is checked into the tree and tested." And this is the
case here.
I think it's a problem of the OOo web infrastructure if it does not
include FIXED issues in the "My Issues" list.

I think we should set this one here to FIXED, again, simply because
this is by definition the state of this issue.

Frank

Set to fixed again.

Closing now

Having the same problem with 1.0.2; it crashes when I try the same
query. What I do is: entery the query into the SQL view, then push the
button to switch to SQL Design View.

Frank Schoenheit,

I understand that the developers need a way to mark an issue as FIXED,
so they can easily see which issues still need to be addressed. In
some environments, there is an additional status of CONFIRMED, which
would be useful in this case. This issue was marked FIXED/CLOSED, yet
I can still reproduce the error. If I had the option of CONFIRMED,
then I could mark an issue as CONFIRMED when _I_, the user, am able to
confirm that it's finished.

Thanks!

Luigi, I agree that closing the issue was done too rashly, because it
then completely vanishes from the radar. I would say it needs to be
verified in an publicly available build before closing it, which has
not been the case here.

However, I cannot leave this as reopened. And be it simply because
_we_ (the developers) will get questions from other sides why it
hasn't been fixed in the mean time. And, in fact, it _has_ been fixed,
but the fix was never targeted for 1.0.2, thus it is not surprising
that you didn't find it therein.

For your requirement of beeing involved in verifying this (I would
like to call it verify, because "confirm" is used for the action of
setting a bug from UNCONFIRMED to NEW): I support this. It is a leak
in the defined life cycle of a bug
(http://www.openoffice.org/issues/bug_status.html) that there no
involvement of the submitter is planned. (Though, from my experiences
in Bugzilla as well as IssueZilla, I can ensure you that a lot of the
submitters do not care as much as you do :).
*But*, this is a problem of the issue life cycle, and I encourage you
to raise this in the public mailing lists (e.g. discuss@ooo), so we
get a solution satisfies all of us.

For this issue here, I set it back to FIXED (sorry, but it _is_
fixed), but will not close it. Additionally, I set the target
milestone to 1.1 Beta, because this (at the latest) is the public
release where the fix will be included.
From the date of the original FIXED state, I assume that the problem
is solved in the OOO 643C build. Could you please check it there, and
then either re-open or VERIFY it?

Thanks :)
Frank

Open again to send it to our QA

Marc, could you please verify.

Thx.

Ocke

set to fixed

verified in internal version, 

fixed in public 644 m build
see http://www.openoffice.org/dev_docs/source/644/

change subcomponent to 'none'