OpenOffice.info

Hallo Robert, hallo Wolfram,

so wie es bei meinen Tests aussieht, kann die GUI keine Kriterien (Bedingungen) verarbeiten, wenn die Abfrage auf einer Abfrage mit Alias-Namen beruht.

Wenn man in der Abfrage"qry_balancenotzero" die Spalte "debit" hinzufügt und da Kriterium "> 0" eingibt, funktioniert es auch nicht. Die Fehlermeldung gibt aus, das die Spalte "a_value" nicht gefunden wird. Und a_value wird von Alias "debit" repräsentiert. Das ist der Bug.

Gruß

acco

Edit 1: Der Bug wird größer. Ich habe alle Alias-Namen aus der Abfrage entfernt und versucht in Abfrage "qry_balancenotzero" das Kriterium "> 0" einzugeben in der ehemaligen "balance" Spalte - die heißt jetzt "IFNULL( "a_value", 0 ) + IFNULL( "b_value", 0 )" das geht auch nicht. Es kommt "Syntaxfehler in SQL-Ausdruck" dahinter: SQL-Status: HY000, Fehler-Code: 1000 syntax error - unexpected $end - expecting BETWEEN or IN or SQL_TOKEN_LIKE.

Also funktionieren in der GUI auch Abfragen mit Kriterien nicht, die auf Abfragen mit berechneten Feldern basieren.

Edit 2: GUI-Problem zusammengefasst:
Wenn in der 2. Abfrage ein Kriterium in eine Spalte eingegeben wird, in der in der 1. Abfrage kein direkter Bezug auf eine Tabellenspalte gegeben ist, dann kommt eine Fehlermeldung. Das betrifft bisher Spalten mit Alias-Namen und berechnete Spalten.

Hallo Wolfram,

das Bug-Verhalten scheint noch etwas tiefer zu liegen. Ich habe da jetzt noch etwas Zeit zum Testen und einmal nachgeprüft. Ich kann die Funktion völlig raus nehmen. Dann kommt eine Fehlermeldung, die verständlicher ist: Die Tabellenangabe zu dem verbliebenen Feld "b_value" fehlte ihm. Habe ich eingesetzt. Und dann kam es noch etwas dicker, so dass da irgendetwas mit dem Alias über die GUI nicht funktioniert. Jetzt war in der ersten Abfrage zwar "tab_b"."b_value" untergebracht, sollte aber mit "balance" in der zweiten Frage ansprechbar sein. Sobald ich aber eine Abfrage mit einem Kriterium formuliere, steht da statt "balance" > 0 → "b_value" > 0
Ich versuche einmal die erste Abfrage so weit auseinander zu dröseln, dass erst einmal kein Fehler auftritt. Vielleicht ist es ja schon der Umgang mit einem Alias aus der ersten in der zweiten Abfrage. Erst nach der Beseitigung solch eines Bugs kann dann die nächste Stufe folgen.
Alles Sachen, die mir nie aufgefallen sind, weil ich zwar eventuell die Felder in der GUI-Ansicht zusammenklicke, aber die Bedingungen immer direkt in SQL formuliere.

Edit1: Was mir gerade auffällt: Wenn ich die entsprechende Filtereingabe direkt in der Abfrage "qry_balance" mache, dann nimmt die GUI die Formulierung an. Es scheint da also empfindliche Probleme mit dem Subselect zu geben.

Gruß

Robert

Hallo Robert und Acco,

der Aufhänger für das Ganze war ja mal das merkwürdige "WHERE". Hier lag acco richtig mit dem Hinweis auf den Formularfilter, da stand tatsächlich ein einsames Blank drin.
Gruss,
Wolfram

Hallo acco,

geht ja weniger darum, wie das von vornherein hätte vermieden werden können, sondern auf welche Eingabe in der ersten Abfrage die GUI der zweiten Abfrage allergisch reagiert. Und das hast Du jetzt gefunden. Damit lässt sich auch eine Bugmeldung formulieren.

Gruß

Robert

Hallo Robert, hallo Wolfram,

WSO hat geschrieben:Aber, neues Problem :
Wenn ich versuche, eine Where-Klausel auf ein mit IFNULL ... definiertes Feld zu legen will,
bringt die grafische Oberfläche beim Auflösen des generierten Statements einen Fehler.
In SQL-Editor (native) funktioniert das gleiche (wie erwartet) einwandfrei.

Wenn die IFNULL-Bedingungen in der Abfrage gelöscht werden, kann in der GUI das Kriterium "> 0" eingegeben werden. Allerdings ist dann das Abfrage-Ergebnis falsch, eben weil die Null-Werte nicht auf "0" gesetzt werden. Abhelfen könnte ein Defaultwert "0" in den leeren Tabellenspalten, aber vermutlich möchte Wolfram in seiner DB im Feld Debit oder Credit keine "0" stehen haben, wenn es (noch) keinen Vorgang (Rechnung) dazu gibt. Sonst hätte er das wohl so gemacht.

Gruß

acco

Hallo Wolfram, hallo acco,

die Abfrage greift auf eine andere Abfrage zu. Der erste Zugriff, den ich jetzt einmal probiert habe, ist, die andere Abfrage zu einer Ansicht zu machen. Dann klappt auch das Filtern im grafischen Modus. Sonst habt Ihr Recht: Das ganze wird mit einem SQL-Fehler nicht ausgeführt. Da gilt es jetzt zu suchen, was die grafische Benutzeroberfläche zum Wanken bringt.

Gruß

Robert

Ja acco stimmt genau.
Eine view will ich aber nicht aus der Abfrage machen.
Meine Tests mit views (in der V4.1) haben die Verwaltungsmöglichkeiten (GUI) der darunter liegen Tabellen so eingeschränkt, dass ich lieber die Abfragen native editiere.

Gruß,
Wolfram

Hallo Robert, hallo Wolfram,

ja, über den Standardfilter beim Aufruf der Abfrage funktioniert das auch bei mir.

Soweit ich Wolfram verstanden habe, geht es um die fest eingestellte Angabe des Kriteriums im GUI-Abfrage-Entwurf. Wenn ich da als Kriterium > 0 eingebe, läßt die Abfrage sich nicht ausführen: "Syntaxfehler in SQL-Ausdruck" kommt als Fehlermeldung.

Schalte ich die Design-Ansicht aus und bin im SQL-Fenster und gebe da ergänzend ein : .." where "balance" > 0" dann funktioniert es. Schalte ich die Design-Ansicht wieder aus, ist das Kriterium "> 0" richtig eingetragen, aber bei ausführen der Abfrage kommt wieder die Fehlermeldung. Versuche ich jetzt die Design-Ansicht wieder auszuschalten um im SQL-Fenster zu sein, wird das mit obiger Fehlermeldung verweigert.

Natürlich bleibt der Weg, die Abfrage "qry_balance" als Ansicht zu erstellen und diese Ansicht als Grundlage für die Abfrage "qry_balancenotzero" mit eingetragenem Kriterium "> 0" zu nehmen, das wird funktionieren. Ich weiß aber nicht, ob das in Wolframs Konzept paßt.

Gruß

acco

Hallo Wolfram, hallo acco,

vielleicht habe ich da etwas nicht richtig verstanden - aber bei mir ist das Ganze in der Abfrage direkt über die Filtereigenschaften möglich.

Gruß

Robert

Ja danke,
so habe ich das Problem auch umgangen.
Dann hoffen wir mal, dass sich die GUI im nächsten Release vielleicht verbessert wird.
Gruss,
Wolfram

Hallo Wolfram,

das funktioniert in der GUI nicht, warum weiß ich nicht. Wenn Du die Abfrage aber mit "in SQL-Ansicht bearbeiten" öffnest und die Where-Klausel da anhängst, funktioniert es.

Wie Du siehst, war ich so frei die Klausel auf >0 zu ändern.

Gruß

acco

ups sorry, dann hier nochmal:
https://www.dropbox.com/s/tt6ln8pzllxb3 ... blem-2.odb
Gruss,
Wolfram

Hallo Wolfram,

WSO hat geschrieben:Versuche mal in der Abfrage "qry_balancenotzero" für das Feld "balance" eine Bedingung (< 0) einzutragen,

Das würde ich gerne, aber in der DB sind nur 3 Tabellen, keine Abfrage.

Gruß

acco

Guten Morgen acco,
danke für die Antwort.
Das Problem mit dem "WHERE" in der Abfrage habe ich lösen können:
Ich habe die Abfragen in allen Ebenen gelöscht und neu gemacht (mit der grafischen Oberfläche).
Danach erschien das "Where" nicht mehr, die Abfrage läuft.

Aber, neues Problem :
Wenn ich versuche, eine Where-Klausel auf ein mit IFNULL ... definiertes Feld zu legen will,
bringt die grafische Oberfläche beim Auflösen des generierten Statements einen Fehler.
In SQL-Editor (native) funktioniert das gleiche (wie erwartet) einwandfrei.
Habe das hier auf das Wesentliche reduziert:
https://www.dropbox.com/s/z9d7mcl9xhg61 ... roblem.odb

Versuche mal in der Abfrage "qry_balancenotzero" für das Feld "balance" eine Bedingung (< 0) einzutragen,
die Abfrage lässt sich nicht mehr ausführen.

Im native SQL gibt es kein Problem mit der um die Bedingung ergänzte Abfrage: Habe mir erstmal damit geholfen Abfragen dieser Art native zu editieren, wird mit steigender Komplexität abr recht aufwendig

Ist die aktuelle Version der grafischen Editors nur mit Einschränkungen nutzbar,
oder habe ich wieder einen Anwendungfehler vor mir?

Danke für deine Mühe und sonnigen Gruss von den kanarischen Inseln,
Wolfram

Hallo Wolfram,

so wie das im Screenshot aussieht ist nach dem "where" ein Leerzeichen. Vielleicht ist im Formular, genauer im Formularfilter, ein Leerzeichen vorhanden (übriggeblieben). Normalerweise meckert dann Base beim abspeichern, aber es ist möglich. Beim Aufruf des Formulars kommt dann die Meldung "Fehler in SQL-Syntax". Vielleicht hilft Dir das?

Gruß

acco