SQLITE ifnull komisches verhalten

[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]

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!

[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)

[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

[jobo]

Ja, sehe ich auch so. Und spaßig finde ich es, weil wir hier kein VBA Forum oder sowas sind, sondern naja, ist ja bekannt. Der Begriff "Typ" sollte also ein Begriff sein, und das Thema wird ja immer wieder mal auch hier genüßlich filetiert. Also die Typenhandhabung in Delphi. Warum in der DB und den gebauten Tabellen dieses Thema schlampiger behandelt werden sollte erschließt sich mir nicht.
Aber was solls, es schafft Arbeitsplätze, solange sich keiner drum kümmert.

[mkinzler]

Zitat:

Warum in der DB und den gebauten Tabellen dieses Thema schlampiger behandelt werden sollte erschließt sich mir nicht.

Ist aber leider so. In einer Hochsprache würde niemand auf die Idee kommen alles in Strings zu Packen, um "flexibel" zu bleiben. In Datenbanken sieht man dass aber leider seht oft.

[nahpets]

Naja, Strings würd' ich da nicht nehmen, lieber direkt Variant oder OleVariant. Da kann dann wirklich alles rein und wird sicherlich auch irgendwie interpretiert werden