Auswahlfehler für Feld *N.

[andreaspr@aon.at]

Wenn der Eingangsparameter Char ist, macht digits ein DEC(36, 31) daraus.
Du müsstest das Ergebnis entsprechend casten.
Besser ist jedoch die Lösung vom Ralf.

[Fuerchau]

Das verhindert jedoch nicht unbedingt, dass der Select abstürzt.
Der Grund liegt in der Optimierung, dass vor der Umwandlung in Dec auch ungültige Daten vorbeikommen können.

DIGITS mach aus einem numerischen Feld ein Zeichenfeld ohne Komma und Vorzeichen, also ein 11,2-Feld wird zu CHAR(11).
Durch Aotocast (s.o. 31,9) wird eben versucht, ein numerisches Feld aus dem Zeichenfeld zu generieren. Wenn da nun keine Ziffern drinstehen, knallts.

Wie ist der Wert denn genau aufgebaut?
Hast du da immer 7 Ziffern oder ist das variabel?
Bei festen Stellen kannst du den Between auch mit Zeichenkonstanten machen "between '0000000' and '9999999'".
Bei variablen Zeichenlängen geht es auch folgendermaßen:

right('0000000' concat substr(f4, 1, 7), 7) between '0000000' and '9999999'

[dibe]

Hmm,
ein select alpafeld, digits(alpafeld) from ... zeigt mit


Schlüssel DIGITS (XX )
0000000051 00000000000000000000000000000051000000000000000000 0000000000000



daher bin ich von alpa2num ausgegangen nicht von Num2Alpa

das ist mein Fehler.

Dieser ist beim verbinden mit einer anderen Datei aufgetreten, die "between" prüfung sollte mir schon den fehlerhaften Satz zeigen.

ohne digits hat alles funktioniert, Danke
DiBe

[Fuerchau]

Das ist der Fluch der bösen Tat, dass die SQL-Programmierer uns das Denken abnehmen wollen.
Früher gab es einen Typefehler, heute versucht man auf Teufel komm raus alle Werte zu casten.

Schlechtestes Beispiel:
select * from teil where tefirm = '2' and tweknr = 000

Was fällt auf? Genau, da hat einer die Hochkommata vergessen.
Bis V5R4, bzw. V6R1 PTFx wurde automatisch daraus:

select * from teil where tefirm = '2' and tweknr = cast(000 as char(3))

und es konnte sogar ein Index verwendet werden.
Seit irgendeinem Stand wird aber nun daraus:

select * from teil where tefirm = '2' and cast(tweknr as dec(3, 0)) = 000

Daraus folgt, dass kein Index verwendet werden kann. Wir konnten uns halt nur nicht erklären, warum der SQL auf einmal so langsam wurde.
Bis aus irgend einem Grunde mal ein Blank in das Feld TEWKNR rutschte, was dann beim Cast auf die Schnautze fällt. Nun ist SQL bei solchen Fehlern inzwischen doch sehr gesprächig geworden und man konnte den ominösen Cast in der Fehlermeldung sehen.

Wer diese Entscheidung, die Reihenfolge der Autocasts zu ändern getroffen hat, gehört in die Wüste geschickt. Solche Fehler werden lange Zeit nicht entdeckt, erst wenn zufällig andere Daten drinstehen oder der Optimizer die Daten in einer anderen Reihenfolge liest.
Folgendes Beispiel:

select dec(Feld, 5, 0) from myfile where feld >= '0'

leider wird zuerst der cast und danach die Whereklausel ausgeführt, ob ihrs glaubt oder nicht.
Erst so funktionierts:
select dec(case when Feld > '0' then Feld else null, 5, 0) from myfile where feld >= '0'

[KingofKning]

Erst so funktionierts:
select dec(case when Feld > '0' then Feld else null, 5, 0) from myfile where feld >= '0'

Hallo,
ich wollte jetzt Dein Beispiel nehmen um aus meiner Datei nur numerische Daten zu bekommen.
Leider hast Du da wohl einen Syntax Fehler eingebaut und ich bin zu doof ihn zu finden.

Kannst Du mich mal bitte erhellen.

GG 4336

[KingofKning]

Es war das End und nicht die Lerche.......