Hallo,

ich habe ein kleines Problem mit einer Abfrage:
SELECT artikel FROM artikel WHERE
artikel LIKE 'HTS25_30';
OR artikel =3D 'HTS25_30'
OR artikel LIKE 'HTS25%30'
OR artikel LIKE 'HTS25_30'
ORDER BY artikel DESC LIMIT 1 ;

Mit diesem Statement erhalte ich aber nicht immer eine Lösung, manchmal g=
arkeine, obwohl ein Datensatz definitiv in der Tabelle artikel vorhanden is=
t.

Ich habe Werte wie
RX680__3
HTS25_30
HTS10130

die ich durchlaufen muss. Da ich vorher nie weiss, welcher Wert das kommt, =
habe ich es eben mit dem OR zusammengestrickt, aber es scheint Probleme mit=
dem LIKE zu geben. Kann das mal jemand prüfen, wo ich einen Fehler gemac=
ht habe. Komischerweise "frisst" er ein gekürztes Statement mit
SELECT artikel FROM artikel WHERE
artikel LIKE 'HTS25_30'
ORDER BY artikel DESC LIMIT 1 ;

ebenfalls nicht, obwohl die Werte
HTS25130
HTS25230
HTS25330

in der Datenbank stehen!!

Danke schonmal im Voraus

Daniel Seichter


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

am 14.07.2006, um 14:03:16 +0200 mailte Daniel Seichter folgendes:
> Hallo,
>
> ich habe ein kleines Problem mit einer Abfrage:
> SELECT artikel FROM artikel WHERE
> artikel LIKE 'HTS25_30';
> OR artikel =3D 'HTS25_30'
> OR artikel LIKE 'HTS25%30'
> OR artikel LIKE 'HTS25_30'
> ORDER BY artikel DESC LIMIT 1 ;

Warum prüfst Du so oft auf dasselbe?


>
> Mit diesem Statement erhalte ich aber nicht immer eine Lösung, manchm=
al garkeine, obwohl ein Datensatz definitiv in der Tabelle artikel vorhan=
den ist.

Hä? Mit immer derselben Frage und denselben Daten in der DB?



>
> Ich habe Werte wie
> RX680__3
> HTS25_30
> HTS10130
>
> die ich durchlaufen muss. Da ich vorher nie weiss, welcher Wert das
> kommt, habe ich es eben mit dem OR zusammengestrickt, aber es scheint
> Probleme mit dem LIKE zu geben. Kann das mal jemand prüfen, wo ich
> einen Fehler gemacht habe. Komischerweise "frisst" er ein gekürztes
> Statement mit
> SELECT artikel FROM artikel WHERE
> artikel LIKE 'HTS25_30'
> ORDER BY artikel DESC LIMIT 1 ;
>
> ebenfalls nicht, obwohl die Werte

Wie sollte die Datenbank Dein SQL 'fressen'? Bekommst Du einen Fehler,
wenn ja, welchen?


> HTS25130
> HTS25230
> HTS25330
>
> in der Datenbank stehen!!

test=3D*# select * from artikel ;
artikel
----------
HTS25_30
HTS_30
HTS25130
HTS10130
HTS25130
HTS25230
HTS25330
(7 rows)

test=3D*# SELECT artikel FROM artikel WHERE artikel LIKE 'HTS25_30' ORDER
BY artikel DESC LIMIT 1 ;
artikel
----------
HTS25330
(1 row)






>
> Danke schonmal im Voraus

Kann es sein, daß Du vielleicht lieber mit REGEX suchen willst?
Aber ich hab die Aufgabe noch nicht so ganz verstanden...

test=3D*# SELECT artikel FROM artikel WHERE artikel ~ '^HTS.*25';
artikel
----------
HTS25_30
HTS25130
HTS25130
HTS25230
HTS25330
(5 rows)




Andreas
--
Andreas Kretschmer (Kontakt: siehe Header)
Heynitz: 035242/47215, D1: 0160/7141639
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
=3D=3D=3D Schollglas Unternehmensgruppe =3D=3D=3D

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

"Daniel Seichter" <dseichter [at] radiomatic.com> writes:

> Kann das mal jemand prüfen, wo ich einen Fehler gemacht
> habe. Komischerweise "frisst" er ein gekürztes Statement mit

> SELECT artikel FROM artikel WHERE
> artikel LIKE 'HTS25_30'
> ORDER BY artikel DESC LIMIT 1 ;
>
> ebenfalls nicht, obwohl die Werte
> HTS25130
> HTS25230
> HTS25330

Wie sehen denn die DDL-Statements aus? Auf dem ersten Blick sieht es
nach einem char-vs-varchar-Problem aus.

Gruß
Andreas

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Hallo Andreas

> Wie sehen denn die DDL-Statements aus? Auf dem ersten Blick sieht es
> nach einem char-vs-varchar-Problem aus.

CREATE TABLE "public"."artikel" (
"artikel" CHAR(12) NOT NULL,
"kurztext" CHAR(123),
"beschreibung" TEXT,
CONSTRAINT "artikel_pkey" PRIMARY KEY("artikel"),
) WITH OIDS;

Grüße

Daniel


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Hallo,


> Wie sollte die Datenbank Dein SQL 'fressen'? Bekommst Du einen Fehler,
> wenn ja, welchen?

> HTS25130
> HTS25230
> HTS25330
>
> in der Datenbank stehen!!

test=3D*# select * from artikel ;
artikel
----------
HTS25130
HTS25130
HTS25230
HTS25330
(4 rows)

> test=3D*# SELECT artikel FROM artikel WHERE artikel LIKE 'HTS25_30' ORDER
> BY artikel DESC LIMIT 1 ;
> artikel
>----------
> HTS25330

und genau das funktioniert nicht! Ich weiss nicht, warum, ich ging in der V=
ergangenheit IMMER davon aus, wenn ich nur eine Stelle nicht weiss, dass ic=
h dann mit dem '_' eben alle Artikel mit mit dem Schema 'HTS25_30' erhalte.=
Und dies geht leider nicht.

Grüße und Danke

Daniel


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

"Daniel Seichter" <dseichter [at] radiomatic.com> writes:

> Hallo Andreas
>
>> Wie sehen denn die DDL-Statements aus? Auf dem ersten Blick sieht es
>> nach einem char-vs-varchar-Problem aus.
>
> CREATE TABLE "public"."artikel" (
> "artikel" CHAR(12) NOT NULL,

Aus <http://www.postgresql.org/docs/8.1/static/datatype-character.html>:

| values of type character will be space-padded; values of type
| character varying will simply store the shorter string.

Also entweder mit dem LIKE auch auf die Leerzeichen matchen, oder ein
varchar daraus machen a la

alter table artikel alter artikel type varchar(12);

Gruß
Andreas

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo [at] postgresql.org so that your
message can get through to the mailing list cleanly

am 14.07.2006, um 14:49:44 +0200 mailte Daniel Seichter folgendes:
> Hallo Andreas
>
> > Wie sehen denn die DDL-Statements aus? Auf dem ersten Blick sieht es
> > nach einem char-vs-varchar-Problem aus.
>
> CREATE TABLE "public"."artikel" (
> "artikel" CHAR(12) NOT NULL,

Ja, und CHAR(N) wird mit Leerzeichen gefüllt. Daher kommen
wahrscheinlich Deine Probleme.


Andreas
--
Andreas Kretschmer (Kontakt: siehe Header)
Heynitz: 035242/47215, D1: 0160/7141639
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
=3D=3D=3D Schollglas Unternehmensgruppe =3D=3D=3D

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

am 14.07.2006, um 14:55:33 +0200 mailte Daniel Seichter folgendes:
> und genau das funktioniert nicht! Ich weiss nicht, warum, ich ging in
> der Vergangenheit IMMER davon aus, wenn ich nur eine Stelle nicht
> weiss, dass ich dann mit dem '_' eben alle Artikel mit mit dem Schema
> 'HTS25_30' erhalte. Und dies geht leider nicht.

CHAR(N) versus VARCHAR(N).

http://www.postgresql.org/docs/8.1/interactive/datatype-char acter.html


Andreas
--
Andreas Kretschmer (Kontakt: siehe Header)
Heynitz: 035242/47215, D1: 0160/7141639
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
=== Schollglas Unternehmensgruppe ===

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

GEL=D6ST:

>> CREATE TABLE "public"."artikel" (
>> "artikel" CHAR(12) NOT NULL,

> Ja, und CHAR(N) wird mit Leerzeichen gefüllt. Daher kommen
> wahrscheinlich Deine Probleme.
Ich habe nun das Feld als varchar(x) umgeändert und nun funktioniert ALLE=
S einwandfrei.

Vielen Dank, werde mir einen Vermerk in meinem Buch machen, um genauer abzu=
wägen, wann char und wann varchar.

Wünsche ein schönes Wochenende

Daniel


---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org