Oracle: column = 'N' geht nicht, column <> 'J' geht???

[Phoenix]

Ich bin grad echt am Verzweifeln.

Ich habe eine Tabelle mit einem als NVARCHAR2(1) deklarierten Feld (PLGDRK_MUSTER), in das ich nur die Werte 'J' und 'N' eintragen kann. Das ist durch eine Constraint sichergestellt.

Ich habe etliche Testdaten drin, einige mit J und einige mit N in dem Feld.

Nun Frage ich die Tabelle ab:

SELECT * FROM TBL_PLG_DRUCKJOB WHERE PLGDRK_MUSTER = 'N'; Resultat: Leere Ergebnismenge

SELECT * FROM TBL_PLG_DRUCKJOB WHERE PLGDRK_MUSTER = 'J'; Resultat: Leere Ergebnismenge

Und jetzt wirds echt knifflig:
SELECT * FROM TBL_PLG_DRUCKJOB WHERE PLGDRK_MUSTER <> 'N'; Resultat: Alle Datensätze mit 'J'

SELECT * FROM TBL_PLG_DRUCKJOB WHERE PLGDRK_MUSTER <> 'J'; Resultat: Alle Datensätze mit 'N'

WARUM zum Teufel funktioniert die Abfrage mit = nicht?

Ein SELECT * FROM TBL_PLG_DRUCKJOB WHERE substr(PLGDRK_MUSTER,1,1) = 'N'; Funktioniert übrigens seltsamerweise. Sieht aber unschön aus. Meine zwei Kollegen und ich sind da grad am Verzweifeln. Hat hier jemand eine logische Erklärung für dieses Verhalten?

Das tritt übrigens generell auf, also nicht nur aus der Anwendung raus, sondern auch via sqlplus.

Hier zum Nachvollziehen die Tabelle mit Testdaten:

Code:

  CREATE TABLE "TBL_PLG_DRUCKJOB" 
   (   "PLGDRK_ID" NCHAR(32) DEFAULT SYS_GUID() NOT NULL ENABLE, 
   "PLGDRK_ARBEITSPLATZ" NVARCHAR2(128) NOT NULL ENABLE, 
   "PLGDRK_DRUCKER" NVARCHAR2(128), 
   "PLGDRK_MATNUMMER" NVARCHAR2(6) NOT NULL ENABLE, 
   "PLGDRK_AUFTRAGSNUMMER" NVARCHAR2(128) NOT NULL ENABLE, 
   "PLGDRK_MUSTER" NVARCHAR2(1) NOT NULL ENABLE, 
   "PLGDRK_WERT1" NVARCHAR2(255), 
   "PLGDRK_WERT2" NVARCHAR2(255), 
   "PLGDRK_WERT3" NVARCHAR2(255), 
   "PLGDRK_WERT4" NVARCHAR2(255), 
   "PLGDRK_WERT5" NVARCHAR2(255), 
   "PLGDRK_WERT6" NVARCHAR2(255), 
   "PLGDRK_WERT7" NVARCHAR2(255), 
   "PLGDRK_WERT8" NVARCHAR2(255), 
   "PLGDRK_WERT9" NVARCHAR2(255), 
   "PLGDRK_WERT10" VARCHAR2(20 BYTE), 
   "PLGDRK_GESAMTANZAHL" NUMBER NOT NULL ENABLE, 
   "PLGDRK_STAPELGROESSE" NUMBER, 
   "PLGDRK_JOBSTATUS" NUMBER NOT NULL ENABLE, 
   "PLGDRK_DRUCKERZAEHLER_INITIAL" NUMBER, 
   "PLGDRK_ANZAHLGEDRUCKT" NUMBER NOT NULL ENABLE, 
   "PLGDRK_ERSTELLT" TIMESTAMP (6) DEFAULT SYSDATE NOT NULL ENABLE, 
   "PLGDRK_AKTUALISIERT" TIMESTAMP (6) DEFAULT SYSDATE NOT NULL ENABLE, 
    CHECK (PLGDRK_MUSTER='J' OR PLGDRK_MUSTER='N' ) ENABLE, 
    PRIMARY KEY ("PLGDRK_ID") ENABLE
   ) ;

Code:

-- INSERTING into TBL_PLG_DRUCKJOB
Insert into "TBL_PLG_DRUCKJOB" ("PLGDRK_ID","PLGDRK_ARBEITSPLATZ","PLGDRK_DRUCKER","PLGDRK_MATNUMMER","PLGDRK_AUFTRAGSNUMMER","PLGDRK_MUSTER","PLGDRK_WERT1","PLGDRK_WERT2","PLGDRK_WERT3","PLGDRK_WERT4","PLGDRK_WERT5","PLGDRK_WERT6","PLGDRK_WERT7","PLGDRK_WERT8","PLGDRK_WERT9","PLGDRK_WERT10","PLGDRK_GESAMTANZAHL","PLGDRK_STAPELGROESSE","PLGDRK_JOBSTATUS","PLGDRK_DRUCKERZAEHLER_INITIAL","PLGDRK_ANZAHLGEDRUCKT","PLGDRK_ERSTELLT","PLGDRK_AKTUALISIERT") values ('409865B97A59491AA805E67B611E58DA','PCAP02','Zebra','123456','11.111.111','N','120','1','0407','0409',null,null,null,null,null,null,99999,0,3,null,0,to_timestamp('10.04.07 16:21:31,000000000','DD.MM.RR HH24:MI:SS,FF'),to_timestamp('10.04.07 16:22:13,000000000','DD.MM.RR HH24:MI:SS,FF'));
Insert into "TBL_PLG_DRUCKJOB" ("PLGDRK_ID","PLGDRK_ARBEITSPLATZ","PLGDRK_DRUCKER","PLGDRK_MATNUMMER","PLGDRK_AUFTRAGSNUMMER","PLGDRK_MUSTER","PLGDRK_WERT1","PLGDRK_WERT2","PLGDRK_WERT3","PLGDRK_WERT4","PLGDRK_WERT5","PLGDRK_WERT6","PLGDRK_WERT7","PLGDRK_WERT8","PLGDRK_WERT9","PLGDRK_WERT10","PLGDRK_GESAMTANZAHL","PLGDRK_STAPELGROESSE","PLGDRK_JOBSTATUS","PLGDRK_DRUCKERZAEHLER_INITIAL","PLGDRK_ANZAHLGEDRUCKT","PLGDRK_ERSTELLT","PLGDRK_AKTUALISIERT") values ('7C12DB4CBC08427289BE50FCBE102F40','PCAP02','Zebra','123456','11.111.111','N','120','1','0407','0409',null,null,null,null,null,null,99999,0,3,null,0,to_timestamp('10.04.07 16:23:12,000000000','DD.MM.RR HH24:MI:SS,FF'),to_timestamp('10.04.07 16:23:20,000000000','DD.MM.RR HH24:MI:SS,FF'));
Insert into "TBL_PLG_DRUCKJOB" ("PLGDRK_ID","PLGDRK_ARBEITSPLATZ","PLGDRK_DRUCKER","PLGDRK_MATNUMMER","PLGDRK_AUFTRAGSNUMMER","PLGDRK_MUSTER","PLGDRK_WERT1","PLGDRK_WERT2","PLGDRK_WERT3","PLGDRK_WERT4","PLGDRK_WERT5","PLGDRK_WERT6","PLGDRK_WERT7","PLGDRK_WERT8","PLGDRK_WERT9","PLGDRK_WERT10","PLGDRK_GESAMTANZAHL","PLGDRK_STAPELGROESSE","PLGDRK_JOBSTATUS","PLGDRK_DRUCKERZAEHLER_INITIAL","PLGDRK_ANZAHLGEDRUCKT","PLGDRK_ERSTELLT","PLGDRK_AKTUALISIERT") values ('2DB4BA02381844FDBE1FE246E8077144','PCAP02','Zebra','123456','22.222.222','J',null,'1',null,null,null,null,null,null,null,null,1,0,3,null,0,to_timestamp('10.04.07 16:29:26,000000000','DD.MM.RR HH24:MI:SS,FF'),to_timestamp('10.04.07 18:13:40,000000000','DD.MM.RR HH24:MI:SS,FF'));
Insert into "TBL_PLG_DRUCKJOB" ("PLGDRK_ID","PLGDRK_ARBEITSPLATZ","PLGDRK_DRUCKER","PLGDRK_MATNUMMER","PLGDRK_AUFTRAGSNUMMER","PLGDRK_MUSTER","PLGDRK_WERT1","PLGDRK_WERT2","PLGDRK_WERT3","PLGDRK_WERT4","PLGDRK_WERT5","PLGDRK_WERT6","PLGDRK_WERT7","PLGDRK_WERT8","PLGDRK_WERT9","PLGDRK_WERT10","PLGDRK_GESAMTANZAHL","PLGDRK_STAPELGROESSE","PLGDRK_JOBSTATUS","PLGDRK_DRUCKERZAEHLER_INITIAL","PLGDRK_ANZAHLGEDRUCKT","PLGDRK_ERSTELLT","PLGDRK_AKTUALISIERT") values ('50426C48FA194FC992ED49F73778D9BF','PCAP02','Zebra','123456','22.222.222','J',null,'1',null,null,null,null,null,null,null,null,1,0,3,null,0,to_timestamp('10.04.07 16:29:31,000000000','DD.MM.RR HH24:MI:SS,FF'),to_timestamp('10.04.07 18:13:47,000000000','DD.MM.RR HH24:MI:SS,FF'));
Insert into "TBL_PLG_DRUCKJOB" ("PLGDRK_ID","PLGDRK_ARBEITSPLATZ","PLGDRK_DRUCKER","PLGDRK_MATNUMMER","PLGDRK_AUFTRAGSNUMMER","PLGDRK_MUSTER","PLGDRK_WERT1","PLGDRK_WERT2","PLGDRK_WERT3","PLGDRK_WERT4","PLGDRK_WERT5","PLGDRK_WERT6","PLGDRK_WERT7","PLGDRK_WERT8","PLGDRK_WERT9","PLGDRK_WERT10","PLGDRK_GESAMTANZAHL","PLGDRK_STAPELGROESSE","PLGDRK_JOBSTATUS","PLGDRK_DRUCKERZAEHLER_INITIAL","PLGDRK_ANZAHLGEDRUCKT","PLGDRK_ERSTELLT","PLGDRK_AKTUALISIERT") values ('4DDD72AB28AE4A5881070A76A2C1CB12','PCAP02','Zebra','123456','22.222.222','N',null,'1',null,null,null,null,null,null,null,null,99999,0,3,null,0,to_timestamp('10.04.07 16:29:32,000000000','DD.MM.RR HH24:MI:SS,FF'),to_timestamp('10.04.07 16:29:33,000000000','DD.MM.RR HH24:MI:SS,FF'));
Insert into "TBL_PLG_DRUCKJOB" ("PLGDRK_ID","PLGDRK_ARBEITSPLATZ","PLGDRK_DRUCKER","PLGDRK_MATNUMMER","PLGDRK_AUFTRAGSNUMMER","PLGDRK_MUSTER","PLGDRK_WERT1","PLGDRK_WERT2","PLGDRK_WERT3","PLGDRK_WERT4","PLGDRK_WERT5","PLGDRK_WERT6","PLGDRK_WERT7","PLGDRK_WERT8","PLGDRK_WERT9","PLGDRK_WERT10","PLGDRK_GESAMTANZAHL","PLGDRK_STAPELGROESSE","PLGDRK_JOBSTATUS","PLGDRK_DRUCKERZAEHLER_INITIAL","PLGDRK_ANZAHLGEDRUCKT","PLGDRK_ERSTELLT","PLGDRK_AKTUALISIERT") values ('01057CD20E3E40389FABEFD11421874C','PCAP02','Zebra','A10002','Sonderetikett','N',null,null,null,null,null,null,null,null,null,null,1,0,3,null,0,to_timestamp('10.04.07 17:18:55,000000000','DD.MM.RR HH24:MI:SS,FF'),to_timestamp('10.04.07 17:18:57,000000000','DD.MM.RR HH24:MI:SS,FF'));
Insert into "TBL_PLG_DRUCKJOB" ("PLGDRK_ID","PLGDRK_ARBEITSPLATZ","PLGDRK_DRUCKER","PLGDRK_MATNUMMER","PLGDRK_AUFTRAGSNUMMER","PLGDRK_MUSTER","PLGDRK_WERT1","PLGDRK_WERT2","PLGDRK_WERT3","PLGDRK_WERT4","PLGDRK_WERT5","PLGDRK_WERT6","PLGDRK_WERT7","PLGDRK_WERT8","PLGDRK_WERT9","PLGDRK_WERT10","PLGDRK_GESAMTANZAHL","PLGDRK_STAPELGROESSE","PLGDRK_JOBSTATUS","PLGDRK_DRUCKERZAEHLER_INITIAL","PLGDRK_ANZAHLGEDRUCKT","PLGDRK_ERSTELLT","PLGDRK_AKTUALISIERT") values ('B87CE14E94EC4B188D4B151742EFEB69','PCAP02','Zebra','123456','99.999.999','J','123','123','123','123',null,null,null,null,null,null,1,0,3,null,0,to_timestamp('10.04.07 18:14:01,000000000','DD.MM.RR HH24:MI:SS,FF'),to_timestamp('10.04.07 18:14:12,000000000','DD.MM.RR HH24:MI:SS,FF'));
Insert into "TBL_PLG_DRUCKJOB" ("PLGDRK_ID","PLGDRK_ARBEITSPLATZ","PLGDRK_DRUCKER","PLGDRK_MATNUMMER","PLGDRK_AUFTRAGSNUMMER","PLGDRK_MUSTER","PLGDRK_WERT1","PLGDRK_WERT2","PLGDRK_WERT3","PLGDRK_WERT4","PLGDRK_WERT5","PLGDRK_WERT6","PLGDRK_WERT7","PLGDRK_WERT8","PLGDRK_WERT9","PLGDRK_WERT10","PLGDRK_GESAMTANZAHL","PLGDRK_STAPELGROESSE","PLGDRK_JOBSTATUS","PLGDRK_DRUCKERZAEHLER_INITIAL","PLGDRK_ANZAHLGEDRUCKT","PLGDRK_ERSTELLT","PLGDRK_AKTUALISIERT") values ('AEF98DD9FE374E609B89838BFACA0A5A','PCAP02','Zebra','123456','99.999.999','N','123','123','123','123',null,null,null,null,null,null,99999,0,3,null,0,to_timestamp('10.04.07 18:14:03,000000000','DD.MM.RR HH24:MI:SS,FF'),to_timestamp('10.04.07 18:14:07,000000000','DD.MM.RR HH24:MI:SS,FF'));

[Elvis]

Hatte jetzt keine Böcke das über .Net zu Testen, erst recht nicht den CR Provider rauszukramen.
Aaaber siehe Anhang, im PL/SQL Developer, einfach als query abgesetzt gates, genauso als dynamic cursor.

Du solltest mal zum Test die Net-Optin deaktivieren und über den Ora Client auf die Daten zugreifen.
Die CR Ora Kompos hatten bei nicht-trivialen Dingsens schon immer Probleme im Net-Modus.
Ihre selbstgebastelte Implementierung eines Ora Clients ist nicht vollständig.

btw: Ihr solltet eurem DB-Fritzen mal einen Programmierkurs gönnen, damit er live erleben kann was für ein widerlicher Krampf es ist mit solch blödsinnigen Doppelmoppel-ich-packe-den-Tablenamen-in-die-Spalten Tabellen zu arbeiten.

[Phoenix]

Also es geht bei uns auch nicht, wenn ich den Raptor (SQl Developer) verwende und es geht hier auch nicht, wenn wir via Toad auf die Ora gehen. Und das von keinem Client aus. Das ist also vollkommen unabhängig von der Zugriffsart auf die DB.

@Spaltennamen: Das ist ungeheuer geschickt, wenn wir Statements automatisch generieren und ein Spaltenname in mehreren Tabellen vorkommt (z.B. die Matnummer, die es in sehr vielen Tabellen gibt). Nix mit Alias erzeugen und irgendwo merken und den ganzen Quatsch

[Elvis]

Zitat von Phoenix:

Also es geht bei uns auch nicht, wenn ich den Raptor (SQl Developer) verwende und es geht hier auch nicht, wenn wir via Toad auf die Ora gehen.

Zumindest TOAD benutzt mittlerweile die CR Kompos ohne Client, soweit ich weiß. Benutze das Viech nicht.

Ich habe es hier in einer lokalen VM mit Ora 9.2 getestet. (Uniode CLient & Server)
Edit: In einer anderen VM mit Ora 10 XE ging es auch, auch dort Unicode Client & Server.
Wenn du zum Beistift einen non-Unicode Client & Unicode Server hast, kann es hier schnell in die Hose gehen.
Kurzfristige Lösung: Spalte auf VarChar ändern
bessere Lösung: Unicode für alle Maschinen als Default CharSet benutzen.

Zitat:

@Spaltennamen: Das ist ungeeuer geschickt, wenn wir Statements automatisch generieren und ein Spaltenname in mehreren Tabellen vorkommt (z.B. die Matnummer, die es in sehr vielen Tabellen gibt). Nix mit Alias erzeugen und irgendwo merken und den ganzen Quatsch

Also ich möchte mit Möglichst wenig Aufwand im Mapping aus meinen Klassen SQLs generieren können, das heißt möglichst SpaltenName==Eigenschaft.
Da ich immer von möglichen Kollisionen ausgehen muss muss ich also auch immer mit Aliasen arbeiten.
Ist sicherlich Geschmackssache, wenn ihr das mit eurem ORM autom. ohne Handarbeit hinkriegt und nicht auch mal so Abfragen machen müsst kann das DB Schema wohl so hässlich sein wie es will.

[Angel4585]

funktioniert das:

SELECT * FROM TBL_PLG_DRUCKJOB WHERE trim(PLGDRK_MUSTER) = 'J'; macht Oracle da vllt irgendwelche Zeichen dran?

[Phoenix]

Hrm.. mit Trim geht es, genauso wie auch mit substr(feld,1,1)...

Echt Seltsam... wie gesagt: Wir sind hier so langsam am Ende mit unserem Latein...
EIGENTLICH müsste das mit dem einfachen '=' ja klappen, wenn ein != bzw. ein <> tut. und bei Elvis scheints auch zu gehen? Echt sonderbar.

[Angel4585]

hmm.. du fängst bei Zeichen 1 an zu lesen.. gibts evtl ein Zeichen 0?

[dfried]

Zitat von Phoenix:

Hrm.. mit Trim geht es, genauso wie auch mit substr(feld,1,1)...

Wie ELvis schon gesagt hat liegt es vermutlich an den Unicode-Einstellungen von Server bzw. Client, mit TRIM und SUBSTR funktioniert es deshalb, weil diese beiden Funktionen als Result immer VARCHAR2 haben und eben nicht NVARCHAR2 wie der eigentliche Spaltentyp!

[Phoenix]

Nein. PL/SQL indiziert bei Subtsr ab 1.
Beispiel:

substr('Test Informatik', 1, 6)
Ergebnis: 'Test I'

[Elvis]

Zitat von Phoenix:

Hrm.. mit Trim geht es, genauso wie auch mit substr(feld,1,1)...

Dann ist es ein Unicode problem.
Funktionen arbeiten bereits mit dem Client-seitigen CharSet.
In den Tabellen sind die Daten aber als Unicode drin (NVarChar).
Wie man Oracle so kennt gibt es halt immer wieder komplett sinnlose und nicht nachvollziehbare Macken. Das Ergebnis einer Funktion und die Ausgabe einer Spalte direkt aus einer Tabelle können verschiedene Charsets haben.

Zitat:

Echt Seltsam... wie gesagt: Wir sind hier so langsam am Ende mit unserem Latein...
EIGENTLICH müsste das mit dem einfachen '=' ja klappen, wenn ein != bzw. ein <> tut. und bei Elvis scheints auch zu gehen? Echt sonderbar.

Was sagt SQL+ ?
Was sind die Char sets auf Client und Server?

Nachtrag:
@dfried
Nope, Trim ist eine Art compiler magic, die nicht nur für CLob und VarChar existiert. Packst du NVarChar rein wirst du auch NVarChar rauskriegen.
Wäre ja schlimm, wenn man keine Unicode-Werte trimmen könnte.

Zitat von Phoenix:

Nein. PL/SQL indiziert bei Subtsr ab 1.
Beispiel:
substr('Test Informatik', 1, 6)
Ergebnis: 'Test I'

dfried hat schon Recht. SubStr(mööp,1,1) gibt das erste Zeichen.
Da die Umwandlung innerhalb des Servers passiert (die Session läuft im client Char set), wird es auch korrekt behandelt.

edit#15000: Warum landen ständig Kommas in meinem Text?