SQLITE ifnull komisches verhalten

[Devil1925]

Habe die Abfrage jetzt gerade mal angepasst:

SQL-Code:

Select I.Keyname, I.Value, I.Abhaengig, T.Abhaengig_Value from INITAB I
LEFT JOIN (Select Sectionname, Keyname, Value as Abhaengig_Value from INITAB) T on T.Keyname = I.Abhaengig
where ifnull(T.Abhaengig_Value, 1) = 1

Trotzdem bekomme ich noch immer nicht die gewünschten ergebnisse...

[nahpets]

Ok, die Screenshots sind nicht die Tabellen, sondern die Ergebnisse mit nicht zwingend verständlichen Namen.

Die Spaltenüberschrift Value1 hatte ich als Namen der Spalte Value1 verstanden.

Es ist aber wohl die von SQLite vorgenommene Nummerierung von nicht eindeutigen Spaltennamen in der Ergebnismenge.

Danke für die Verwirrung.

Wo finde ich denn jetzt eigentlich die Tabellendefinition von INITAB, um da etwas eindeutigere Informationen zu bekommen, statt der Spalten der nicht zufriedenstellenden Abfrageversuche?

Dashier

SQL-Code:

Select I.Keyname, I.Value, I.Abhaengig, T.Abhaengig_Value from INITAB I
LEFT JOIN (Select Sectionname, Keyname, Value from INITAB) T on T.Keyname = I.Abhaengig
where ifnull(T.Value, 1) = 1

würde ich auch anders formulieren:

SQL-Code:

Select I.Keyname, I.Value, I.Abhaengig, T.Value As Abhaengig_Value from INITAB I
LEFT JOIN (Select Sectionname, Keyname, Value from INITAB where ifnull(Value, 1) = 1) T on T.Keyname = I.Abhaengig

Warum die Einschränkung für die Teilmenge im Left-Join ausserhalb des Unterselects? Das führt beim Lesen (und eventuell auch bei der Interpretation durch die Datenbank?) sehr schnell zu Verwirrung.

Bau Dir bitte mal für dasda (Select Sectionname, Keyname, Value from INITAB where ifnull(Value, 1) = 1) 'ne View und binde die, nachdem ihre Ergebnisse als richtig verifiziert wurden, ins Left Join ein.
Eventuell wird dann die Abfragelogik leichter les- und verstehbar.

[Devil1925]

Zitat von nahpets:

Ok, die Screenshots sind nicht die Tabellen, sondern die Ergebnisse mit nicht zwingend verständlichen Namen.

Die Spaltenüberschrift Value1 hatte ich als Namen der Spalte Value1 verstanden.

Es ist aber wohl die von SQLite vorgenommene Nummerierung von nicht eindeutigen Spaltennamen in der Ergebnismenge.

Danke für die Verwirrung.

Entschuldigung für die Verwirrung durch das erste Bild.

Zitat von nahpets:

Wo finde ich denn jetzt eigentlich die Tabellendefinition von INITAB, um da etwas eindeutigere Informationen zu bekommen, statt der Spalten der nicht zufriedenstellenden Abfrageversuche?

Hier einmal die genaue Tabellendefinition:
Tabelle: INITAB
Spalten:
Sectionname VARCAHR
Keyname VARCHAR
Value VARCHAR
Abhaengig VARCHAR

Zitat von nahpets:

Dashier

SQL-Code:

Select I.Keyname, I.Value, I.Abhaengig, T.Abhaengig_Value from INITAB I
LEFT JOIN (Select Sectionname, Keyname, Value from INITAB) T on T.Keyname = I.Abhaengig
where ifnull(T.Value, 1) = 1

würde ich auch anders formulieren:

SQL-Code:

Select I.Keyname, I.Value, I.Abhaengig, T.Value As Abhaengig_Value from INITAB I
LEFT JOIN (Select Sectionname, Keyname, Value from INITAB where ifnull(Value, 1) = 1) T on T.Keyname = I.Abhaengig

Warum die Einschränkung für die Teilmenge im Left-Join ausserhalb des Unterselects? Das führt beim Lesen (und eventuell auch bei der Interpretation durch die Datenbank?) sehr schnell zu Verwirrung.

Es geht ja darum, dass ich in der endabfrage sowohl die Datensätze haben möchte, welche im Value der unterabfrage eine 1 stehen haben, als auch die, welche keinen Datensatz in der Unterabfrage zugeordnet haben. Somit brauche ich aus der Gesamtabfrage alle Datensätze die in der Spalte (so in der Abfrage benannt) "Abhaengig_Value" entweder NULL oder 1 stehen haben.

Zitat von nahpets:

Bau Dir bitte mal für dasda (Select Sectionname, Keyname, Value from INITAB where ifnull(Value, 1) = 1) 'ne View und binde die, nachdem ihre Ergebnisse als richtig verifiziert wurden, ins Left Join ein.
Eventuell wird dann die Abfragelogik leichter les- und verstehbar.

man kann in SQLITE Views einbauen? das ist mir neu, kann aber auch sein das ich das einfach noch nicht wusste.

[nahpets]

Keine Ahnung, ob SQLite Views kann, würd' es aber zumindest mal probieren.

Siehe http://www.tutorialspoint.com/sqlite/sqlite_views.htm

Value ist VarChar, Du fragst aber auf nummerisch ab.

Ist ein leeres Value nun Null oder ein Leerstring?

Bitte mal noch ein Select * from INITAB als Screenshot, damit man das auch mal sehen kann.

Bei Value = VarChar wäre die Mindeständerung:

SQL-Code:

Select I.Keyname, I.Value, I.Abhaengig, T.Value As Abhaengig_Value from INITAB I
LEFT JOIN (Select Sectionname, Keyname, Value from INITAB where ifnull(Value, '1') = '1') T on T.Keyname = I.Abhaengig

[Aviator]

Zitat von nahpets:

Keine Ahnung, ob SQLite Views kann, würd' es aber zumindest mal probieren.

Natürlich kann SQLite Views. Siehe hier: https://www.sqlite.org/lang_createview.html

[Devil1925]

Danke, der Denkanstoß fehlte mir! Durch das Ändern von [CODE=SQL]... where ifnull(T.Value, 1) = 1[CODE] auf ... where ifnull(T.Value, '1') = '1' funktioniert das auch!

(mich wundert es nur, dass da kein Fehler ausgeworfen wurde und der die Abfrage einfach ausgeführt hat, aber vielleicht bin ich da auch einfach vom MSSQL Managementstudio verwöhnt)

[Devil1925]

Zitat von Aviator:

Zitat von nahpets:

Keine Ahnung, ob SQLite Views kann, würd' es aber zumindest mal probieren.

Natürlich kann SQLite Views. Siehe hier: https://www.sqlite.org/lang_createview.html

OK, danke für die Info!

[jobo]

Zitat von Devil1925:

Danke, der Denkanstoß fehlte mir! Durch das Ändern von

Code:

.. where ..'1' = '1'..

funktioniert das auch!

(mich wundert es nur, dass da kein Fehler ausgeworfen wurde und der die Abfrage einfach ausgeführt hat, aber vielleicht bin ich da auch einfach vom MSSQL Managementstudio verwöhnt)

Siehe mein Post #2.
SQLite ist nicht pingelig mit Typen.
Der Typ des Ausdrucks "ifnull(<feld>,1)" ist (mir) erstmal unbekannt.
Genaugenommen wohl auch sqlite, da die Funktion verschiedenste Spaltentypen als Eingangsparameter schluckt.
Um sicherzugehen, dass ein Vergleich mit festem Typ funktioniert, muss man die gewünschten Typen auch gesichert herbeiführen. Also Cast oder sowas. Hast Du gemacht mit Anführungszeichen. (Ich wäre mir übrigens nicht sicher, dass Deine Methode hinreichend sicher ist)
Mein Vorschlag, am anderen Ende des "=" die gleiche Funktion einzusetzen, nur mit fixen Parametern, war ein erster Wurf, um Dich auf das Problem aufmerksam zu machen.

P.S.: Auch in anderen RDBMS gibt es solche Funktionen, deren Ausgabetyp notgedrungen (oder eleganter Weise) variieren kann. Das wird dynamisch zum Zeitpunkt des Aufrufs bestimmt und ist idR auch dokumentiert, wie die Funktionen das machen.
Also an der Ecke schadet es nie, 2x hinzusehen.

[nahpets]

Also da muss ich jetzt mal was loswerden!

Wieso scheren sich Entwickler, die bei Delphi die Typsicherheit loben (aber durchaus auch andere), bei der Nutzung von SQL 'nen Teufel um die Datentypen?

Da wird verglichen auf teufelkommraus, aber mal links und rechts des Gleichheitszeichens den gleichen Datentyp verwenden?

Warum, solange es nicht knallt, wird es wohl schon gehen.

Und wenn nicht: Erst ist es mal ein Probelm der Datenbank und deren fehlerhaften Funktionen.

Übrigens ein Problem, dass ich schon meine ganze Zeit als Entwickler immer und immerwieder beobachten durfte, ist also nix persönliches oder explizites hier in diesem Thread oder Forum.

Nur ganz allgemein und extrem nervend.

Man sucht Fehler in 'ner Datenbank und deren Implementierung.

Kaum achtet man mal auf den Datentyp, schon hat sich das Problem in Luft aufgelöst.

Vermutlich ist das größte Problem bei der Nutzung von SQL, dass es bei unterschiedlichen Datentypen extrem fehlertolerant ist, aber diese Fehlertoleranz nicht immer im Sinne der Wünsche der Nutzer erfolgt, sondern im Sinne der technischen Implementierung der Datenbank.

Oder kurz:

Wenn ich Zeichenfolgen zu vergleichen habe, dann vergleiche ich Zeichenfolgen.

Wenn ich nummerische Werte zu vergleichen habe, dann vergleiche ich nummerische Werte.

Muss ich das Eine mit dem Anderen vergleichen, dann nutze ich die entsprechend Typkonvertierung und verlasse mich nicht darauf, dass die Datenbank selbständige die Typkonvertierung nutzt, von der ich meine, dass sie im konkreten Fall die Richtige sei.
Das kann funktionieren, muss aber nicht. Und der Fehler liegt dann nicht in der Datenbank, sondern sitzt davor.

So, genug gemeckert

[Devil1925]

Zur Kenntnis genommen!

Zitat von nahpets:

Und der Fehler liegt dann nicht in der Datenbank, sondern sitzt davor.

Das ist sowieso in 90% der Fehlerfall.

Und damit noch einen schönen Start in den Feierabend