Alpha-Zeichen in Artikelnr V6R1

[Fuerchau]

Was soll dieser Blödsinn?
(dec(case when artikelnr > '0'
then artikelnr else '0' end, 5, 0)

Dein Problem ist, dass die Dec-Umwandlung immer durchgeführt wird und zwar unabhängig ob der 2. Vergleich dann zieht oder nicht.
Wofür ist die Dec-Konvertierung denn überhaupt gut?
Da reicht doch auch ArtikelNr >= '0'!

[B.Hauser]

Was willst Du, nur die Artikel-Nr., die andere Zeichen als Ziffern enthalten?
Da gibt es mehrere Möglichkeiten.

1. Ohne Regular Expressions

Select FieldX, ....
   From ...
   Where Trim(Translate(FieldX, '          ', '1234567890')) > ''

2. Mit Regular Expressions - müsste ab Release 7.1 verfügbar sein

Select FieldX 
   From ...
   Where RegexP_Like(Trim(FieldX), '[^\d]')

Birgitta

[Fuerchau]

Für RegEx in SQL sind Zusatzoptionen zu installieren die gerne vergessen werden.

[KingofKning]

Was willst Du, nur die Artikel-Nr., die andere Zeichen als Ziffern enthalten?
Da gibt es mehrere Möglichkeiten.

1. Ohne Regular Expressions

Select FieldX, ....
   From ...
   Where Trim(Translate(FieldX, '          ', '1234567890')) > ''

2. Mit Regular Expressions - müsste ab Release 7.1 verfügbar sein

Select FieldX 
   From ...
   Where RegexP_Like(Trim(FieldX), '[^\d]')

Birgitta

Hallo,

ich will eigentlich nur die Artikel-Nr haben die numerisch sind. Sprich alles andere wie mit -A oder Texte wie Artikel-Nr (kommt vom Import aus Excel) will ich nicht.

[Fuerchau]

Dann nimm Birgittas Funktion:

Trim(Translate(FieldX, ' ', '1234567890')) <> ''

Der Translate ersetzt alle Ziffern durch Blanks, der Trim entfernt alle Blanks vor und nachher.
Wenn dann noch was über ist, ist es ungleich Leer.

[B.Hauser]

Dann must Du lediglich bei meiner 1. Lösung das Größerzeichen durch ein Gleichheitszeichen ersetzen und schon hast Du die numerischen Artikeln-Nr.

Birgitta

[Fuerchau]

Stimmt, da habe ich das doch glatt negiert;-).

[KingofKning]

Danke für die Hilfe,

wobei die Frage warum das SQL anders reagiert als das Query noch nicht beantwortet ist.
vermutlich gibt es dazu auch keine logische Antwort.

[Fuerchau]

Das liegt dann an der unterschiedlichen Betrachtung des Optimisers.
Hast du z.B. eine Where-Klausel und es kann ein Index genommen werden, kommt das Ergebnis u.U. an den fehlerhaften Daten nicht vorbei.
Ist ein Tablescan erforderlich oder ein ungünstiger Index, liegen die falschen Daten ggf. mit im Zwischenergebnis.

Nun kommt es auch noch auf dein Release an.
Je nach dem ob V5, V6, V7 arbeitet der Optimizer immer mal wieder anders.
Und da nahm der Query/400 die sog. ClassicalQueryEngine (CQE) und SQL die SQLWQueryEngine (SQE).
Ab irgend einem Release (frag Birgitta) wurde die CQE abgeschafft.