Base SQL-Abfragen

de-users
#1

Hallo,

in Base ist die Design-Ansicht für Abfragen zwar ganz hübsch und einfach zu bedienen, bei komplexeren Abfragen stößt sie aber schnell an ihre Grenzen. Also: Per Hand SQL eingeben. Dabei gebe ich natürlich alles strukturiert ein, also mit Einrückungen usw. Funktioniert auch gut.
Nun mein Problem: Wenn ich so eine Abfrage speichere und schließe, erscheint sie beim nächsten Öffnen vollkommen unstrukturiert mit dem Effekt, daß ich mein eigenes SQL erst mal nicht überblicke.
Gibt es da Abhilfe durch irgendeine Einstellung, die ich nicht kenne, oder ist das eher ein Wunsch an die Entwickler.
Zur Zeit speichere ich solche Abfragen immer noch einmal mit einem externen Editor (Notepad++), aber das ist auch nur eine schlechte Behelfslösung.

Ahoi

Thomas

#2

Hallo Thomas,

in Base ist die Design-Ansicht für Abfragen zwar ganz hübsch und einfach
zu bedienen, bei komplexeren Abfragen stößt sie aber schnell an ihre
Grenzen. Also: Per Hand SQL eingeben. Dabei gebe ich natürlich alles
strukturiert ein, also mit Einrückungen usw. Funktioniert auch gut.
Nun mein Problem: Wenn ich so eine Abfrage speichere und schließe,
erscheint sie beim nächsten Öffnen vollkommen unstrukturiert mit dem
Effekt, daß ich mein eigenes SQL erst mal nicht überblicke.
Gibt es da Abhilfe durch irgendeine Einstellung, die ich nicht kenne,
oder ist das eher ein Wunsch an die Entwickler.

Eine Abhilfe, die für Dich aber vielleicht nicht tauglich ist: Wähle im SQL-Eingabemodus SQL-Kommando direkt ausführen. Dann wird das, was Du eingegeben hast, nicht mehr von der Base-GUI angefasst. Nachteil dieser Methode ist, dass die Abfragen nicht mehr editierbar sind.

Zur Zeit speichere ich solche Abfragen immer noch einmal mit einem
externen Editor (Notepad++), aber das ist auch nur eine schlechte
Behelfslösung.

Ich weiß nicht, ob Notepad++ SQL-Code entsprechend farblich darstellen kann. Mit KWrite unter Linux/KDE ist die farbliche Hervorhebung auch gegeben - in sofern eine für mich bessere Alternative, wenn es denn der Base-Editor nicht so tut.

Ich habe gerade die Bug-Reports durchgesucht. Eigentlich war ich mir sicher, dass ich da etwas von dem Wunsch gelesen habe, dass die Returns und Strukturierungen nicht durch die GUI angefasst würden.
Das schein nicht so ganz einfach zu sein, da sonst nicht Lionel als derjenige, der am meisten Datenbank-Bugs fixt, selbst den folgenden Bug-Report geschrieben hat:
https://bugs.freedesktop.org/show_bug.cgi?id=42713

Gruß

Robert

#3

Hallo Thomas,

Nun mein Problem: Wenn ich so eine Abfrage speichere und schließe,
erscheint sie beim nächsten Öffnen vollkommen unstrukturiert mit dem
Effekt, daß ich mein eigenes SQL erst mal nicht überblicke.
Gibt es da Abhilfe durch irgendeine Einstellung, die ich nicht kenne,
oder ist das eher ein Wunsch an die Entwickler.

Eher ein Wunsch. Es gibt meines Wissens keine Einstellung dafür, und ich
schätze, es würde wohl ziemlich viel Arbeit gebrauchen, um das "Hin und
Her" korrekt zu behandeln, weil eben deine SQL-Abfrage parsierbar
innerhalb einer XML-Datei (content.xml der ODB-Datei) bleiben muss, so
wie unten :

<db:query db:command="SELECT &quot;Märchen&quot; FROM
&quot;Tabelle&quot; WHERE &quot;Herkunft&quot; = 'Japan'"
db:name="Requête1"/></db:queries>

Alex

#4

Hallo und vielen Dank für die Antworten.

Ich merke, es ist ein Wunsch, der wohl nicht so bald in Erfüllung geht. Extra einen SQL-Server einzurichten ist mir zu viel Aufwand, so groß ist das Projekt nicht. Ich werde mich also disziplinieren und immer alles schön mit Notepad++ speichern, da wird der Code sehr gut farblich dargestellt.

Thomas

#5

Hallo,

Eher ein Wunsch. Es gibt meines Wissens keine Einstellung dafür, und ich
schätze, es würde wohl ziemlich viel Arbeit gebrauchen, um das "Hin und
Her" korrekt zu behandeln, weil eben deine SQL-Abfrage parsierbar
innerhalb einer XML-Datei (content.xml der ODB-Datei) bleiben muss, so
wie unten :

<db:query db:command="SELECT &quot;Märchen&quot; FROM
&quot;Tabelle&quot; WHERE &quot;Herkunft&quot; = 'Japan'"
db:name="Requête1"/></db:queries>

Sieht das für euch nicht nach einem EasyHack aus?

Im Grunde müsste man doch nur Leerzeichen, Tabulatoren und Zeilenwechsel in der XML-Datei kodiert mitspeichern, so ähnlich wie auch jetzt schon die Anführungszeichen kodiert sind. Letztere müssen ja wohl auch irgenwann für die eigentliche Abfrage dekodiert werden, und genau an dieser Stelle müssten die o.g. Formatierungszeichen einfach nur entfernt werden.

(Oder seh ich das zu einfach?)

Gruß Nino

#6

N´Abend!

Früher bei Star-Office gab es mal das "Adabas D". Heute Adabas 8.xx.

Grüsse

#7

Hallo G. Mohing,

Hallo und vielen Dank für die Antworten.

Ich merke, es ist ein Wunsch, der wohl nicht so bald in Erfüllung
geht. Extra einen SQL-Server einzurichten ist mir zu viel Aufwand,so
groß ist das Projekt nicht. Ich werde mich also disziplinieren und
immer alles schön mit Notepad++ speichern, da wird der Code sehr gut
farblich dargestellt.

Thomas

N´Abend!

Früher bei Star-Office gab es mal das "Adabas D". Heute Adabas 8.xx.

Kannst Du einmal erklären, was das mit der Frage zu tun hat? Es geht um das Editieren von Abfragen, nicht über irgendeine Datenbank, die an Base drangehängt wird. Das Ganze hat nichts mit der verbundenen Datenbank sondern mit der grafischen Benutzeroberfläche und den dortigen Gestaltungsmöglichkeiten zu tun.

Gruß

Robert

#8

Hallo Thomas,

Ich merke, es ist ein Wunsch, der wohl nicht so bald in Erfüllung geht.
Extra einen SQL-Server einzurichten ist mir zu viel Aufwand, so groß ist
das Projekt nicht.

Was hat das mit einem SQL-Server zu tun? Es ging Dir doch um die Möglichkeit, innerhalb von Base auch Returns oder sonstige Formatierungen erhalten zu können. Dafür ist nicht die angeschlossene Datenbank zuständig. Sofern Du die Abfragen nicht anschließend noch als Grundlage für Formulare benötigst geht das zur Zeit, indem Du beim Editieren im SQL-Modus der Abfrage auch den Button "SQL" drückst. Dann wird die Abfrage nicht mehr durch die GUI zurückgestellt.

Gruß

Robert

#9

Hallo Alex,

Eher ein Wunsch. Es gibt meines Wissens keine Einstellung dafür, und ich
schätze, es würde wohl ziemlich viel Arbeit gebrauchen, um das "Hin und
Her" korrekt zu behandeln, weil eben deine SQL-Abfrage parsierbar
innerhalb einer XML-Datei (content.xml der ODB-Datei) bleiben muss, so
wie unten :

<db:query db:command="SELECT &quot;Märchen&quot; FROM
&quot;Tabelle&quot; WHERE &quot;Herkunft&quot; = 'Japan'"
db:name="Requête1"/></db:queries>

Kann eigentlich nicht sein, dass das so kompliziert ist. Schließlich lässt sich eine Abfrage sehr wohl mit Return etc. abspeichern, wenn nur in dem Abfrageeditor der Button "SQL" gedrückt wurde. Dann wird die erstellte Abfrage nicht mehr von der GUI angefasst, beim nächsten Mal zum Editieren auch wieder direkt im SQL-Modus geöffnet und zeigt weiter die Formatierung an.

Einziger Nachteil: Diese Form der Abfrage ist nicht editierbar, also nichts für Leute, die Formulare zur Datenänderung, Datenlöschung oder Dateneingabe damit basteln wollen.

Gruß

Robert

#10

Hallo Robert,

Hallo Thomas,

Ich merke, es ist ein Wunsch, der wohl nicht so bald in Erfüllung geht.
Extra einen SQL-Server einzurichten ist mir zu viel Aufwand, so groß ist
das Projekt nicht.

Was hat das mit einem SQL-Server zu tun?

Das weiß ich auch nicht, kam als Antwort von Guido.

Es ging Dir doch um die Möglichkeit, innerhalb von Base auch Returns oder sonstige Formatierungen erhalten zu können. Dafür ist nicht die angeschlossene Datenbank zuständig. Sofern Du die Abfragen nicht anschließend noch als Grundlage für Formulare benötigst geht das zur Zeit, indem Du beim Editieren im SQL-Modus der Abfrage auch den Button "SQL" drückst. Dann wird die Abfrage nicht mehr durch die GUI zurückgestellt.

Gruß

Robert

Gruß

Thomas

#11

Hallo,

kann mir jemand einen Tipp geben zum Vergleich zweier Tabellen mit Hilfe
eines SQL-Befehls. (Bzw wie ermittelt man die Differenz zweier Tabellen oder
der Result-Sets zweier SELECT-Abfragen zur gleichen Tabelle)?

Danke im voraus
Joachim

#12

Ergänzung: Die "Minus" und "Except" Keywords für ein SQL-Statement funktionieren leider bei der OOBase-HSQLDB-Version nicht, ich finde aber kein Äquivalent.

Joachim

#13

Hallo Joachim,

Ergänzung: Die "Minus" und "Except" Keywords für ein SQL-Statement funktionieren leider bei der OOBase-HSQLDB-Version nicht, ich finde aber kein Äquivalent.

Ich gehe davon aus, dass ich das vor der Niederschrift in das Handbuch
getestet habe:

#14

Hallo Robert,

vielen Dank für Deine blitzschnelle Antwort.

Dein Modell enthält 1 Spalte, mein Modell enthält 3 Spalten zum Vergleich. Ich habe Deine Syntax 3-mal ausprobiert:
1) in Extras/SQL: Dort bekomme ich die Antwort "Befehl erfolgreich ausgeführt"
2) im Abfragebereich/SQL-Abfrage erstellen: Dort bekomme ich die Antwort "Syntax Error"
3) Wenn ich diese Differenz in eine andere Tabelle schreibe, dann ist die neue Tabelle leer

Mein SQL-Befehl lautet:

SELECT "Feld1", "Feld2", "Feld3"
       FROM "Tabelle1"
   MINUS
SELECT "Feld1", "Feld2", "Feld3"
       FROM "Tabelle2"

Wo ist der Wurm?
Joachim

#15

Ergänzung: Die Tabelle 2 ist natürlich kleiner als die Tabelle 1
Joachim

#16

Hallo Joachim,

Dein Modell enthält 1 Spalte, mein Modell enthält 3 Spalten zum Vergleich. Ich habe Deine Syntax 3-mal ausprobiert:
1) in Extras/SQL: Dort bekomme ich die Antwort "Befehl erfolgreich ausgeführt"
2) im Abfragebereich/SQL-Abfrage erstellen: Dort bekomme ich die Antwort "Syntax Error"
3) Wenn ich diese Differenz in eine andere Tabelle schreibe, dann ist die neue Tabelle leer

Entweder habe ich das nicht weiter durchgetestet oder einfach vergessen
aufzuschreiben:
Das funktioniert nur, wenn bei der Abfrage der direkte SQL-Modus (Button
bei der Eingabe im SQL-Modus) gedrückt wird.

Gruß

Robert

#17

Hallo Robert,
danke für Deine 2.Antwort. Wenn man die Abfrage nicht speichert und den Button "Direkt SQL..." drückt, geht der Befehl ohne Murren durch. Beim Speichern kommt trotzdem "Syntax Error...." und beim Ergebnis aufrufen kommt auch eine leere Abfrage zum Vorschein....
Die 2.Tabelle hat 17 Datensätze weniger als die 1.Tabelle (von über 2000) , ist aber ansonsten identisch. (Wenn es nicht ziemlich unweidmännisch wäre, könnte ich das ganze ja manuell durchsuchen....)

Nix für ungut/Joachim

#18

Hallo Joachim,

Hallo Robert,
danke für Deine 2.Antwort. Wenn man die Abfrage nicht speichert und den Button "Direkt SQL..." drückt, geht der Befehl ohne Murren durch. Beim Speichern kommt trotzdem "Syntax Error...." und beim Ergebnis aufrufen kommt auch eine leere Abfrage zum Vorschein....
Die 2.Tabelle hat 17 Datensätze weniger als die 1.Tabelle (von über 2000) , ist aber ansonsten identisch. (Wenn es nicht ziemlich unweidmännisch wäre, könnte ich das ganze ja manuell durchsuchen....)

Beim Speichern kommt nur "Syntax error", wenn Du noch einmal den
SQL-Button drückst. "Syntax error" ist die allroundmeldung von der GUI,
keine Meldung der Datenbank. Ich habe hier folgende gespeicherte Abfrage:

SELECT * FROM "Tabelle1" EXCEPT SELECT * FROM "Tabkopie1"

Aus der zweiten Tabelle habe ich Datensätze entfernt. Ansonsten sind die
Tabellen identisch. Es werden die Datensätze angezeigt, die ich entfernt
habe (9 Felder von unterschiedlichen Typus (Text, Datum, Integer,
Boolsches feld usw.)

Ich kann nicht nachvollziehen, warum Du die Abfrage nicht speichern
kannst. Auch eine Ansicht funktioniert damit.

Gruß

Robert

#19

Hallo Robert,

ich danke Dir wieder sehr für Deine Antwort. Ich habe erneut folgendes ausprobiert:

1) Die Abfrage SELECT * FROM "Alb_Spur_Interpr" EXCEPT SELECT * FROM "AlbSpurInt_Temp1" läuft bei Extra/SQL problemlos
2) Dieselbe Abfrage läuft bei Abfragen/Abfrage in SQL-Sicht erstellen läuft mit dem SQL-Button problemlos, das erzielte Ergebnis ist aber eine leere Tabelle
3) Jetzt habe ich die Abfrage ergänzt: INSERT INTO "AlbSpurInt_Temp2" (SELECT * FROM "Alb_Spur_Interpr" EXCEPT SELECT * FROM "AlbSpurInt_Temp1") Das Ergebnis ist wieder eine leere Tabelle. (Die Tabelle "Alb_Spur_Interpr" hat 2260 Sätze, die Tabelle "AlbSpurInt_Temp1" hat 2243 Sätze)
4) Ich habe das Base-System von Apache auf LibreOffice 3.6.5 umgestellt, aber es bleibt bei denselben Ergebnissen

Ich schicke Dir meine Datenbank und die Fehlermeldungen mit, vielleicht kannst Du den Wurm dort entschlüsseln?

Gruss/Joachim

#20

Hallo Joachim,

ich habe den Haken bei Deiner Datenbank gefunden: Du hast da in der
Tabelle 17 Doppler.
SELECT COUNT( "Alb_Spur_Interpr".* ), "Alb_Spur_Interpr"."AlbumID",
"Alb_Spur_Interpr"."SpurNr", "Alb_Spur_Interpr"."InterpretenID" FROM
"Alb_Spur_Interpr" GROUP BY "AlbumID", "SpurNr", "InterpretenID" HAVING
( ( COUNT( * ) > 1 ) )
Das habe ich einfach einmal in der GUI zusammengeklickt, nachdem mir die
Abfrage auch nichts raus gab.
Zuerst dachte ich, dass das vielleicht an den fehlenden Primärschlüsseln
liegt. Gründe ich die Vergleichstabellen neu mit Primärschlüsseln, so
werden mir viele Datensätze angezeigt.
Da die Abfrage mit EXCEPT nur die Datensätze ausgibt, die in der anderen
Tabelle nicht vorhanden sind blieb die Abfrage leer.
Stelle ich die folgende Abfrage, so werden mir keine Datensätze angezeigt:
SELECT COUNT( "AlbSpurInt_Temp1".* ), "AlbSpurInt_Temp1"."AlbumID",
"AlbSpurInt_Temp1"."SpurNr", "AlbSpurInt_Temp1"."InterpretenID" FROM
"AlbSpurInt_Temp1" GROUP BY "AlbumID", "SpurNr", "InterpretenID" HAVING
( ( COUNT( * ) > 1 ) )
Du kannst also getrost die Tabelle "Alb_Spur_Interpr" löschen und
"AlbSpurInt_Temp1" entsprechend umbenennen.

Gruß

Robert