Daten nicht in der Abfrage
Moderator: Moderatoren
- komma4
- ********
- Beiträge: 5332
- Registriert: Mi, 03.05.2006 23:29
- Wohnort: Chon Buri Thailand Asia
- Kontaktdaten:
Re: Daten nicht in der Abfrage
Welche OOo-Version?
Welches Betriebssystem?
Welche Datenbank (embedded HSQLDB)? Angabe steht in der Statuszeile der ODB)
Was bedeutet "funktioniert soweit"?
Was bedeutet "ohne Eingabe"
Wie sieht die Abfrage denn aus?
Welches Betriebssystem?
Welche Datenbank (embedded HSQLDB)? Angabe steht in der Statuszeile der ODB)
Was bedeutet "funktioniert soweit"?
Was bedeutet "ohne Eingabe"
Wie sieht die Abfrage denn aus?
Cheers
Winfried
aktuell: LO 5.3.5.2 30m0(Build:2) SUSE rpm, unter Linux openSuSE Leap 42.3 x86_64/KDE5
DateTime2 Einfügen von Datum/Zeit/Zeitstempel (als OOo Extension)
Winfried
aktuell: LO 5.3.5.2 30m0(Build:2) SUSE rpm, unter Linux openSuSE Leap 42.3 x86_64/KDE5
DateTime2 Einfügen von Datum/Zeit/Zeitstempel (als OOo Extension)
-
- ********
- Beiträge: 4330
- Registriert: Di, 22.06.2004 12:02
- Wohnort: 71134 Aidlingen
- Kontaktdaten:
Re: Daten nicht in der Abfrage
[quote="Warum 0815"]
Was soll der Blödsinn mit Parameter Is Null ?
Code: Alles auswählen
SELECT "Id", "Nachname", "Vorname", "Studiengang", "Ort" FROM "SE-Datenbank"
WHERE ( LOWER ( "Nachname" ) LIKE LOWER ( :qNachname || '%' )
AND LOWER ( "Vorname" ) LIKE LOWER ( :qVorname || '%' )
AND LOWER ( "Studiengang" ) LIKE LOWER ( :qStudiengang || '%' )
Code: Alles auswählen
OR LOWER ( "Nachname" ) LIKE LOWER ( :qNachname || '%' ) AND :qVorname IS NULL AND :qStudiengang IS NULL AND :qOrt IS NULL
OR LOWER ( "Vorname" ) LIKE LOWER ( :qVorname || '%' ) AND :qStudiengang IS NULL AND :qOrt IS NULL AND :qNachname IS NULL
OR LOWER ( "Studiengang" ) LIKE LOWER ( :qStudiengang || '%' ) AND :qVorname IS NULL AND :qOrt IS NULL AND :qNachname IS NULL
Code: Alles auswählen
OR LOWER ( "Nachname" ) LIKE LOWER ( :qNachname || '%' ) AND :qVorname IS NULL OR :qStudiengang IS NULL OR :qOrt IS NULL
OR LOWER ( "Vorname" ) LIKE LOWER ( :qVorname || '%' ) AND :qNachname IS NULL OR :qStudiengang IS NULL OR :qOrt IS NULL
OR LOWER ( "Studiengang" ) LIKE LOWER ( :qStudiengang || '%' ) AND :qVorname IS NULL OR :qNachname IS NULL OR :qOrt IS NULL
Code: Alles auswählen
OR :qVorname IS NULL AND :qStudiengang IS NULL AND :qOrt IS NULL AND :qNachname IS NULL )
Gruß
Peter
---------------------------------------------------------------------------
Windows 7 Prof. 64-bit SP1, LibreOffice 4.3.6.2 und AOO 4.1.1
Peter
---------------------------------------------------------------------------
Windows 7 Prof. 64-bit SP1, LibreOffice 4.3.6.2 und AOO 4.1.1
Re: Daten nicht in der Abfrage
Hallo Peter,
das kursiert schon häufiger. Ich nehme an, dass hier ein missverständnis der Parameter vorliegt. Ein leerer Parameter soll dazu führen, dass er ignoriert wird, nehme ich jedenfalls an. Nur geschieht das so überhaupt nicht.
Nehme ich die Zeile,
dann wird nur nach dem Nachnamen überhaupt etwas differenziert. Die weiter aufgeführten Parameter sind ohne Beziehung zur Abfrage. Die gehören eigentlich gar nicht dort hin. Da die Parameter nicht NULL sind sondern einen leeren Text transportieren landet so eine Abfrage immer bei 0 Datensätzen.
Erst
macht aus so einer Angabe erst wirklich NULL und bringt wieder Daten in die Abfrage.
Gruß
Robert
das kursiert schon häufiger. Ich nehme an, dass hier ein missverständnis der Parameter vorliegt. Ein leerer Parameter soll dazu führen, dass er ignoriert wird, nehme ich jedenfalls an. Nur geschieht das so überhaupt nicht.
Nehme ich die Zeile
Code: Alles auswählen
OR LOWER ( "Nachname" ) LIKE LOWER ( :qNachname || '%' ) AND :qVorname IS NULL OR :qStudiengang IS NULL OR :qOrt IS NULL
dann wird nur nach dem Nachnamen überhaupt etwas differenziert. Die weiter aufgeführten Parameter sind ohne Beziehung zur Abfrage. Die gehören eigentlich gar nicht dort hin. Da die Parameter nicht NULL sind sondern einen leeren Text transportieren landet so eine Abfrage immer bei 0 Datensätzen.
Erst
Code: Alles auswählen
NULLIF(:qNachname,'')
Gruß
Robert
Re: Daten nicht in der Abfrage
Moin,
und wurde einmal mit der grafischen Benutzeroberfläche zur Abfrageerstellung geöffnet.
Dadurch wurde es zerschossen, und ist kaum noch zu verstehen.
Es dient der Filterung eines Unterformulares, wenn die Parameter z.B. aus einer Filtertabelle übergeben werden.
In diesem Fall wären an die Filtertabelle vier Kontrollfelder gebunden, die die vier Filterkriterien in die Filtertabelle eintragen, das Unterformular ist über die Parameter mit den Filterfeldern verknüpft und bleibt voll beschreibbar. Dabei hat die Funktion, dass leere Filterkriterien nicht berücksichtigt werden, d.h. keine Eingabe im Filterfeld Ort führt zur Anzeige aller gefilterten Datensätze, ohne Filterung nach Ort, weil in der Filtertabelle wirklich NULL steht, wenn in das Kontrollfeld nichts eingegeben wird.
Es handelt sich hierbei um eine im englischen Forum unter anderen, vom USER VILLEROY, ein Genie in meinen Augen, und inzwischen auch von mir, propagierte Methode zum Filtern in Formularen.
Du kannst dir die Methode gerne im Videotutorial 3-5 (s.u.) ansehen.
Das es Probleme gibt, wenn man eine solche Abfrage nicht im Formular benutzt, sondern per Doppelklick öffnet, weil der Parametereingabedialog bei Nichteingabe eines Parameters, wie Robert schreibt, nicht NULL sondern einen leeren String übergibt, ist unglücklich.
Gruß Rik
na, mal immer langsam. Das SQL-Statement lautete mit ziemlicher Sicherheit einmal so:pmoegenb hat geschrieben:Was soll der Blödsinn mit Parameter Is Null ?
Code: Alles auswählen
SELECT
"Id",
"Nachname",
"Vorname",
"Studiengang",
"Ort"
FROM
"SE-Datenbank"
WHERE
( LOWER ( "Nachname" ) LIKE LOWER ( :qNachname || '%' ) OR :qNachname IS NULL)
AND
(LOWER ( "Vorname" ) LIKE LOWER ( :qVorname || '%' ) OR :qVorname IS NULL)
AND
(LOWER ( "Studiengang" ) LIKE LOWER ( :qStudiengang || '%' ) OR :qStudiengang IS NULL)
AND
(LOWER ("Ort") LIKE LOWER (:qOrt || '%' ) OR :qOrt IS NULL)
Dadurch wurde es zerschossen, und ist kaum noch zu verstehen.
Es dient der Filterung eines Unterformulares, wenn die Parameter z.B. aus einer Filtertabelle übergeben werden.
In diesem Fall wären an die Filtertabelle vier Kontrollfelder gebunden, die die vier Filterkriterien in die Filtertabelle eintragen, das Unterformular ist über die Parameter mit den Filterfeldern verknüpft und bleibt voll beschreibbar. Dabei hat
Code: Alles auswählen
IS NULL
Es handelt sich hierbei um eine im englischen Forum unter anderen, vom USER VILLEROY, ein Genie in meinen Augen, und inzwischen auch von mir, propagierte Methode zum Filtern in Formularen.
Du kannst dir die Methode gerne im Videotutorial 3-5 (s.u.) ansehen.
Das es Probleme gibt, wenn man eine solche Abfrage nicht im Formular benutzt, sondern per Doppelklick öffnet, weil der Parametereingabedialog bei Nichteingabe eines Parameters, wie Robert schreibt, nicht NULL sondern einen leeren String übergibt, ist unglücklich.
Gruß Rik
- miniKasse MMove 1.0.6 Base Videotutorial
- Windows 10: AOO, LO Linux Mint: AOO, LO
Re: Daten nicht in der Abfrage
Hallo Rik,
von Fehlern ist hier sicher niemand ausgenommen - auch noch so bekannte User.
Gerade noch einmal getestet, nachdem Dein Post kam:
Es ist egal, ob ich
oder
im Code stehen habe. Bei einem leeren Feld wird immer das gleiche Ergebnis geliefert. Der Sinn von :qNachname IS NULL erschließt sich nicht nur mir nicht, sondern anscheinend auch dem Abfrageeditor (natürlich nur in der SQL-Ansicht eingegeben - der GUI traue ich da nicht über den Weg).
Das liegt sicher daran, dass auch bei einer leeren Eingabe natürlich alle Ergebnisse zählen, die über LIKE abgefragt werden - weil eben :qNachname nicht NULL ist.
Dass eine Abfrage in einem Formular anders verarbeitet wird als außerhalb eines Formulares ist eigentlich ein Unding. Und gerade um eine Abfrage ging es doch - von einem Formular hat der Treaderöffner nicht geschrieben.
Da bleibe ich doch lieber bei Methoden, die übertragbar sind und lasse die Parameter aus einer Filtertabelle lesen.
Gruß
Robert
von Fehlern ist hier sicher niemand ausgenommen - auch noch so bekannte User.
Gerade noch einmal getestet, nachdem Dein Post kam:
Es ist egal, ob ich
Code: Alles auswählen
LOWER ( "Nachname" ) LIKE LOWER ( :qNachname || '%' ) OR :qNachname IS NULL
Code: Alles auswählen
LOWER ( "Nachname" ) LIKE LOWER ( :qNachname || '%' )
Das liegt sicher daran, dass auch bei einer leeren Eingabe natürlich alle Ergebnisse zählen, die über LIKE abgefragt werden - weil eben :qNachname nicht NULL ist.
Dass eine Abfrage in einem Formular anders verarbeitet wird als außerhalb eines Formulares ist eigentlich ein Unding. Und gerade um eine Abfrage ging es doch - von einem Formular hat der Treaderöffner nicht geschrieben.
Da bleibe ich doch lieber bei Methoden, die übertragbar sind und lasse die Parameter aus einer Filtertabelle lesen.
Gruß
Robert
Re: Daten nicht in der Abfrage
Hallo Robert,
Anbei mal die o.a. Abfrage in einem Filterformular, und da funzt es eben mit den leeren Feldern.
Aus meiner Sicht ein Fehler des Parameterdialoges der Abfragen, eine Nichteingabe sollte auch als NULL verarbeitet werden.
Gruß Rik
Wenn meinst Du damit?RobertG hat geschrieben:Von Fehlern ist hier sicher niemand ausgenommen - auch noch so bekannte User.
Genau!RobertG hat geschrieben:Dass eine Abfrage in einem Formular anders verarbeitet wird als außerhalb eines Formulares ist eigentlich ein Unding
Anbei mal die o.a. Abfrage in einem Filterformular, und da funzt es eben mit den leeren Feldern.
Aus meiner Sicht ein Fehler des Parameterdialoges der Abfragen, eine Nichteingabe sollte auch als NULL verarbeitet werden.
Gruß Rik
- Dateianhänge
-
- SE-Datenbank.odb
- (25.86 KiB) 101-mal heruntergeladen
- miniKasse MMove 1.0.6 Base Videotutorial
- Windows 10: AOO, LO Linux Mint: AOO, LO
Re: Daten nicht in der Abfrage
Hallo Rik,
Nun ist das ganze sicher weniger Villeroys Fehler als der Fehler, der in dem System liegt: Jede(r) sieht eine Abfragetechnik und bedenkt nicht, dass die spezielle Konstruktion so nur Sinn macht, wenn sie über das Formular angesteuert wird. Ich habe das Beispiel deshalb einmal heruntergeladen und den Code etwas anders formuliert. Dann passt er sowohl bei einer Abfrage als auch bei der Nutzung der Afrage innerhalb eines Formulars:
wird zu
Diese Formulierung kann ich mit Hilfe von SQL und der integrierten HSQLDB erklären. Die Formulierung, bei der über z.B. :qOrt IS NULL eine Behandlung der vorhergehenden Bedingung ausgeschlossen werden soll ergibt sich für mich nicht aus dem für die HSQLDB zur Verfügung stehenden SQL-Code. Da wird an anderer Stelle etwas verarbeitet, die für mich im Moment nicht einsichtbar ist und offensichtlich auch nicht ausreichend dokumentiert ist. Die Hilfestellung sagt dazu - nichts. Weißt Du eine Quelle, die darüber etwas genaueres aussagt?
Ich werde zum Parameterdialog - vor allem wegen der unterschiedlichen Behandlung leerer Felder - einmal eine Bugbeschreibung zumindest bei LO aufgeben. Dann ist zumindest das unterschiedliche Verhalten schon einmal bekannt. Ob auch etwas geschieht ist natürlich eine andere Frage.
Gruß
Robert
Ich dachte, dass das klar wäre. Das traf in diesem Fall auf Villeroy zu. Das sollte auch mit Sicherheit nicht abwertend rüberkommmen - wer weiß, was ich schon alles für Mist geschrieben habe.F3K Total hat geschrieben:Hallo Robert,Wenn meinst Du damit?RobertG hat geschrieben:Von Fehlern ist hier sicher niemand ausgenommen - auch noch so bekannte User.
Nun ist das ganze sicher weniger Villeroys Fehler als der Fehler, der in dem System liegt: Jede(r) sieht eine Abfragetechnik und bedenkt nicht, dass die spezielle Konstruktion so nur Sinn macht, wenn sie über das Formular angesteuert wird. Ich habe das Beispiel deshalb einmal heruntergeladen und den Code etwas anders formuliert. Dann passt er sowohl bei einer Abfrage als auch bei der Nutzung der Afrage innerhalb eines Formulars:
Code: Alles auswählen
SELECT "ID", "Nachname", "Vorname", "Studiengang", "Ort" FROM "SE-Datenbank" WHERE ( LOWER ( "Nachname" ) LIKE LOWER ( :qNachname || '%' ) OR :qNachname IS NULL ) AND ( LOWER ( "Vorname" ) LIKE LOWER ( :qVorname || '%' ) OR :qVorname IS NULL ) AND ( LOWER ( "Studiengang" ) LIKE LOWER ( :qStudiengang || '%' ) OR :qStudiengang IS NULL ) AND ( LOWER ( "Ort" ) LIKE LOWER ( :qOrt || '%' ) OR :qOrt IS NULL )
Code: Alles auswählen
SELECT "ID", "Nachname", "Vorname", "Studiengang", "Ort" FROM "SE-Datenbank" WHERE ( LOWER ( "Nachname" ) LIKE IFNULL( LOWER ( :qNachname ), '' ) || '%' ) AND ( LOWER ( "Vorname" ) LIKE IFNULL( LOWER ( :qVorname ), '' ) || '%' ) AND ( LOWER ( "Studiengang" ) LIKE IFNULL( LOWER ( :qStudiengang ), '' ) || '%' ) AND ( LOWER ( "Ort" ) LIKE IFNULL( LOWER ( :qOrt ), '' ) || '%' )
Ich werde zum Parameterdialog - vor allem wegen der unterschiedlichen Behandlung leerer Felder - einmal eine Bugbeschreibung zumindest bei LO aufgeben. Dann ist zumindest das unterschiedliche Verhalten schon einmal bekannt. Ob auch etwas geschieht ist natürlich eine andere Frage.
Gruß
Robert
Re: Daten nicht in der Abfrage
Hallo Robert,
Danke, dass du eine BUG-Meldung schreibst.
Vielleicht kannst Du sie hier verlinken, dann kann man bei Zeiten mal nachschauen?
EDIT:
Hallo Robert,
habe gerade meine Abfrage, die vermeintlich nur im Formular laufen soll, mal per Doppelklick geöffnet, und, was soll ich sagen, sie läuft, auch wenn ich was leer lasse, sowohl unter AOO als auch unter LO.
Kannst Du es bitte auch einmal versuchen?
Gruß Rik
In der AOO Hilfe findet man unter Abfrageentwurf, Formulieren von Filterbedingungen diese Erklärung: zugegeben, sehr dürftig.RobertG hat geschrieben:Weißt Du eine Quelle, die darüber etwas genaueres aussagt?
Danke, dass du eine BUG-Meldung schreibst.
Vielleicht kannst Du sie hier verlinken, dann kann man bei Zeiten mal nachschauen?
EDIT:
Hallo Robert,
habe gerade meine Abfrage, die vermeintlich nur im Formular laufen soll, mal per Doppelklick geöffnet, und, was soll ich sagen, sie läuft, auch wenn ich was leer lasse, sowohl unter AOO als auch unter LO.
Kannst Du es bitte auch einmal versuchen?
Gruß Rik
- miniKasse MMove 1.0.6 Base Videotutorial
- Windows 10: AOO, LO Linux Mint: AOO, LO
Re: Daten nicht in der Abfrage
Hallo Rik,
natürlich funktioniert die Abfrage. Der Vergleich für den Parameter wird aber vorher abgeschlossen:
Das angehängte
wird nie erreicht und ergibt nur einen Sinn, wenn dort
steht. Dies gibt der Datenbank die Anweisung, auch leere Ortsbedingungen mitzuteilen. :qOrt ist der Datenbank unbekannt und hat von der Abfrage her keine Bedeutung. :qOrt müsste also in der Abfrage auch auftauchen.
:qOrt kann nur über die interne Verabreitung im Formular mit einem Feld verglichen werden. Die Parameter stehen ja nicht einmal zur Verfügung, wenn ich in einem Formular eine Verknüpfung vom Hauptformular zum Unterformular erstellen will. Da muss also intern so eine Abfrage laufen wie
So eine Abfrage bekomme ich dabei überhaupt nicht zu Gesicht. Sie gäbe der Ergänzung aber eigentlich erst einen Sinn: Durchsuche entweder das Feld "Ort" oder ob das Feld ":qOrt" leer ist.
Ich habe das jetzt einmal in einer Beispieldatenbank durchgetestet. Es werden einmal Parameter aus einer Tabelle gelesen, die im Hauptformular steht. Dadurch sind natürlich NULL-Werte möglich. Vielleicht wäre es wünschenswert, wenn sich der Dialog hier anpasst - aber auch dann müsste eine Abfrage mindestens so weit erweitert werden wie oben beschrieben, dami sie überhaupt einen Sinn ergibt.
----- Nachtrag: -----
Ich bin mir mittlerweile gar nicht mehr sicher, ob so eine Bugmeldung überhaupt begründbar ist. Wird einem leeren Feld NULL über den Parametereingabedialog mitgeteilt, so ergibt sich daraus falscher SQL-Code, wenn ich z.B. "Ort" = :qOrt in der Abfrage stehen habe. Wann wird so ein leeres Feld tatsächlich sinnvoll, so dass auch der eventuell falsche Code noch berücksichtigt werden müsste?
Gruß
Robert
natürlich funktioniert die Abfrage. Der Vergleich für den Parameter wird aber vorher abgeschlossen:
Code: Alles auswählen
LOWER ( "Ort" ) LIKE LOWER ( :qOrt || '%' )
Code: Alles auswählen
OR :qOrt IS NULL
Code: Alles auswählen
OR "Ort" IS NULL
:qOrt kann nur über die interne Verabreitung im Formular mit einem Feld verglichen werden. Die Parameter stehen ja nicht einmal zur Verfügung, wenn ich in einem Formular eine Verknüpfung vom Hauptformular zum Unterformular erstellen will. Da muss also intern so eine Abfrage laufen wie
Code: Alles auswählen
SELECT "ID", "Ort", :qOrt FROM Tabelle WHERE LOWER ( "Ort" ) LIKE LOWER ( :qOrt || '%' ) OR :qOrt IS NULL
Ich habe das jetzt einmal in einer Beispieldatenbank durchgetestet. Es werden einmal Parameter aus einer Tabelle gelesen, die im Hauptformular steht. Dadurch sind natürlich NULL-Werte möglich. Vielleicht wäre es wünschenswert, wenn sich der Dialog hier anpasst - aber auch dann müsste eine Abfrage mindestens so weit erweitert werden wie oben beschrieben, dami sie überhaupt einen Sinn ergibt.
----- Nachtrag: -----
Ich bin mir mittlerweile gar nicht mehr sicher, ob so eine Bugmeldung überhaupt begründbar ist. Wird einem leeren Feld NULL über den Parametereingabedialog mitgeteilt, so ergibt sich daraus falscher SQL-Code, wenn ich z.B. "Ort" = :qOrt in der Abfrage stehen habe. Wann wird so ein leeres Feld tatsächlich sinnvoll, so dass auch der eventuell falsche Code noch berücksichtigt werden müsste?
Gruß
Robert
Re: Daten nicht in der Abfrage
Hallo Robert,
Mein Verständnis ist wie folgt:
Im Formular gibt es ja den "SingleSelectQueryComposer" (Xray), ich denke, der baut alle Selects, Filter- und Sortierkriterien, Parameter, Group by und having clauses usw. zu dem Statement zusammen, das dann den Formularinhalt darstellt. Und der scheint ja nun das IS NULL für ein leeres Eingabefeld so zu verarbeiten, wie beschrieben. Wenn ich einen der Parameter per XRAY analysiere, finde ich die Eigenschaft
ISNULLABLE: in der Api dazu unter
Gruß Rik
Ich denke, ich kann hier nicht viel zu sagen.RobertG hat geschrieben:Wann wird so ein leeres Feld tatsächlich sinnvoll, so dass auch der eventuell falsche Code noch berücksichtigt werden müsste?
Mein Verständnis ist wie folgt:
Im Formular gibt es ja den "SingleSelectQueryComposer" (Xray), ich denke, der baut alle Selects, Filter- und Sortierkriterien, Parameter, Group by und having clauses usw. zu dem Statement zusammen, das dann den Formularinhalt darstellt. Und der scheint ja nun das IS NULL für ein leeres Eingabefeld so zu verarbeiten, wie beschrieben. Wenn ich einen der Parameter per XRAY analysiere, finde ich die Eigenschaft
ISNULLABLE: in der Api dazu unter
Irgendwie alles Hinweise, aber durchsteigen tue ich da nicht. Ich weiß nur, dass beide Methoden, deine und meine, zu einem filterbaren und beschreibbaren Formular führen, und das ist es, was am häufigsten gebraucht wird.com :: sun :: star :: sdbc hat geschrieben:indicates the nullability of values in the designated column
Gruß Rik
- miniKasse MMove 1.0.6 Base Videotutorial
- Windows 10: AOO, LO Linux Mint: AOO, LO
Re: Daten nicht in der Abfrage
Hallo Rik,
ich bin immer noch unschlüssig, ob ich da einen Bug draus melden kann. Ich habe jetzt noch einmal meine Abfragemethode etwas nachgebessert, da dabei dann Werte aus dem Ergebnis fehlen, wenn eventuell Felder leer sind. Dazu habe ich die Tabelle von Dir etwas gelöchert ...
Ergebnis: Beide Abfragearten werden von der GUI so aktzeptiert, nur die mit "Parameter IS NULL" tut eben genau das nicht, wofür sie gedacht ist. Die Abfrage liefert nicht mehr alle Datensätze sondern nur die Datensätze, in denen jedes Feld belegt ist, das in der Abfrage auch untersucht wird. Und genau das ist es ja, was bei dem Einbau der Abfrage in das Formular anders läuft. Da liefert "Parameter IS NULL" alle Datensätze.
Ersetze ich in der Abfrage durch , dann sind wieder alle Datensätze da.
Mal sehen, ob ich daraus eine vernünfige Bugbeschreibung gestalten kann.
Gruß
Robert
ich bin immer noch unschlüssig, ob ich da einen Bug draus melden kann. Ich habe jetzt noch einmal meine Abfragemethode etwas nachgebessert, da dabei dann Werte aus dem Ergebnis fehlen, wenn eventuell Felder leer sind. Dazu habe ich die Tabelle von Dir etwas gelöchert ...
Ergebnis: Beide Abfragearten werden von der GUI so aktzeptiert, nur die mit "Parameter IS NULL" tut eben genau das nicht, wofür sie gedacht ist. Die Abfrage liefert nicht mehr alle Datensätze sondern nur die Datensätze, in denen jedes Feld belegt ist, das in der Abfrage auch untersucht wird. Und genau das ist es ja, was bei dem Einbau der Abfrage in das Formular anders läuft. Da liefert "Parameter IS NULL" alle Datensätze.
Ersetze ich
Code: Alles auswählen
:Parameter IS NULL
Code: Alles auswählen
:Parameter = ''
Mal sehen, ob ich daraus eine vernünfige Bugbeschreibung gestalten kann.
Gruß
Robert
Re: Daten nicht in der Abfrage
Hallo Rik,
ich habe das jetzt als Bug mit einer kleinen Beispieldatenbank gemeldet. Der Unterschied zwischen Abfrage und Formular kommt besonders deutlich raus, wenn einfach nur die Abfrage und das Formular geöffnet werden. Die Abfrage gibt ohne Angabe der Parameter nur 4 Datensätze aus. Das Formular stattdessen mit der gleichen Abfrage, nur über die Formularfelder gefüttert, ergibt 10 Datensätze.
https://bugs.freedesktop.org/show_bug.cgi?id=86852
Mal sehen, ob das irgendjemanden sonst interessiert.
Gruß
Robert
ich habe das jetzt als Bug mit einer kleinen Beispieldatenbank gemeldet. Der Unterschied zwischen Abfrage und Formular kommt besonders deutlich raus, wenn einfach nur die Abfrage und das Formular geöffnet werden. Die Abfrage gibt ohne Angabe der Parameter nur 4 Datensätze aus. Das Formular stattdessen mit der gleichen Abfrage, nur über die Formularfelder gefüttert, ergibt 10 Datensätze.
https://bugs.freedesktop.org/show_bug.cgi?id=86852
Mal sehen, ob das irgendjemanden sonst interessiert.
Gruß
Robert
Re: Daten nicht in der Abfrage
Hallo Robert,
danke schön.
Ich bin gespannt!
Gruß Rik
danke schön.
Ich bin gespannt!
Gruß Rik
- miniKasse MMove 1.0.6 Base Videotutorial
- Windows 10: AOO, LO Linux Mint: AOO, LO
Re: Daten nicht in der Abfrage
Hallo Rik,
das ging dieses Mal äußerst fix:
https://bugs.freedesktop.org/show_bug.cgi?id=86852 - gefixt zur Version LO 4.5 von Lionel.
Ich melde mich, wenn ich das mit dem daily build am Mittwoch erfolgreich nachvollziehen kann. Vermutlich kommt da auch noch irgendeine weitere Meldung, dass sich das noch in der 4.4.0 niederschlagen kann.
Gruß
Robert
das ging dieses Mal äußerst fix:
https://bugs.freedesktop.org/show_bug.cgi?id=86852 - gefixt zur Version LO 4.5 von Lionel.
Ich melde mich, wenn ich das mit dem daily build am Mittwoch erfolgreich nachvollziehen kann. Vermutlich kommt da auch noch irgendeine weitere Meldung, dass sich das noch in der 4.4.0 niederschlagen kann.
Gruß
Robert
Re: Daten nicht in der Abfrage
Hallo Robert, das hoert sich super an. Waere toll wenn das auch zu AOO durchschlagen wurde. Beste Gruesse per Satellit, von irgendwo auf der Ostsee, Rik
- miniKasse MMove 1.0.6 Base Videotutorial
- Windows 10: AOO, LO Linux Mint: AOO, LO