Oracle 8i: Problem mit SQL-Statement

[Tobias F]

Hallo,

bei folgender Abfrage habe ich ein Problem, wobei zu beachten ist, dass "feld" vom Typ NUMBER ist und es sich bei "10,23,35,65" um einen String handelt.
SELECT *
FROM   tabelle
WHERE  to_char(feld) IN ( '10,23,35,65' );

Wenn ich nun diese Query ausführe, erhalte ich logischerweise den Hinweis, dass keine Zeilen gefunden wurden, da er 10,23,35,65 nicht als (vier) einzelne Werte ansieht.

Nun habe ich versucht, den String "10,23,35,65" folgendermaßen umzubauen:
SELECT *
FROM   tabelle
WHERE  to_char(feld) IN ( ''''||replace( '10,23,35,65', ',', ''',''')||'''' );

Aber leider ohne Erfolg. Der String wird anscheinend immer noch als komplette Zeichenkette und nicht als vier einzelne Elemente interpretiert.

Nun bin ich mit meinem SQL-Latein am Ende und hoffe, dass mir jemand einen Tipp geben kann, wie man den SQL-Interpreter dazu "zwingen" kann die '10', '23', '35' und '65' als einzelne Elemente anzusehen.

Schon mal vielen Dank für Eure Hilfe!

Viele Grüße
Tobias

[wahsaga]

hi,

WHERE  to_char(feld) IN ( '10,23,35,65' );

wie sieht es mit

WHERE  to_char(feld) IN ( 10, 23, 35, 65 );

aus?

(dann natürlich den string vorher peinlich genau darauf prüfen, ob auch wirklich daten in diesem format vorliegen.)

gruß,
wahsaga

[wahsaga]

hi,

WHERE  to_char(feld) IN ( 10, 23, 35, 65 );

soory, dann natürlich ohne typecast:

WHERE  feld IN ( 10, 23, 35, 65 );

gruß,
wahsaga

[Tobias F]

Hallo wahsaga,

anscheinend habe ich mich etwas mißverständlich ausgedrückt. Das Problem ist, dass ich den String '10,23,35,65' von einem Subselect geliefert bekomme und ich somit Deinen Lösungsvorschlag nicht verwenden kann.

Ich müßte den String '10,23,35,65' also so hinbiegen, dass der SQL-Interpreter ihn als vier einzelne Strings bzw. Zahlen erkennt.

Falls noch jemand einen Tipp hat wie man das hinbekommen könnte, bedanke ich mich im Voraus!

Grüße
Tobias

hi,

WHERE  to_char(feld) IN ( 10, 23, 35, 65 );

soory, dann natürlich ohne typecast:

WHERE  feld IN ( 10, 23, 35, 65 );

gruß,
wahsaga

[wahsaga]

hi,

Ich müßte den String '10,23,35,65' also so hinbiegen, dass der SQL-Interpreter ihn als vier einzelne Strings bzw. Zahlen erkennt.

hm, dann kommen wir mal wieder auf deinen ansatz im ausgangsposting zurück:

Nun habe ich versucht, den String "10,23,35,65" folgendermaßen umzubauen:
SELECT *
FROM   tabelle
WHERE  to_char(feld) IN ( ''''||replace( '10,23,35,65', ',', ''',''')||'''' );

hast du mal überprüft, was dieser replace liefert?
(in dem du z.b. mal
SELECT replace( '10,23,35,65', ',', ''',''') AS kontrolle
machst, und dir diese spalte dann ausgeben lässt.)

Aber leider ohne Erfolg. Der String wird anscheinend immer noch als komplette Zeichenkette und nicht als vier einzelne Elemente interpretiert.

ja, ich fürchte auch fast, dass das nicht viel weiterbringt.
selbst wenn du das komma durch ',' ersetzen lässt, also dann effektiv
10','23','35','65
herausbekommst, wird das sicher immer noch als string angesehen - also genau so, als ob du im klartext "10','23','35','65" da hinschreiben würdest, und das ist wieder nur _ein_ wert :-/

gruß,
wahsaga

[Tobias F]

Hallo wahsaga,

ich habe befürchtet, dass es für dieses Problem keine Lösung gibt. Aber trotzdem nochmal vielen Dank für deine Hilfe.

Grüße
Tobias

[Roman Pfarrhofer]

Hallo!

ich habe befürchtet, dass es für dieses Problem keine Lösung gibt. Aber trotzdem nochmal vielen Dank für deine Hilfe.

ich kenne die hintergründe nicht, warum dieser string so abgelegt ist - sollten die enthalten werte aber mit anderen daten korrespondieren, dann hast du gleich mal mehrere norm-formen verletzt (sind ja doch für was gut ;-).

also deshalb schlage ich mal vor, daß du beschreibst, warum die daten dort so sind und vielleicht findet man eine lösung, was das problem an der wurzel packt und nicht nur die auswirkung behebt. denn ich vermute, daß die daten warscheinlich anderes abgelegt werden können (was eine änderung des db-designs zur folge haben wird). damit wird ein solches sql-statement gar nicht mehr benötigt (obwohls dafür auch sicher eine lösung gibt - aber weder optimal noch performant).

CU Roman

[Tobias F]

Hallo Roman,

auch wenn ich versucht habe dieses zu umgehen ;-) werde ich die Datenbankstruktur überarbeiten.

Viele Grüße
Tobias