UniKL Logo

Lehrgebiet Informationssysteme

FB Informatik

FB Informatik
 
LG IS
AG DBIS
 Staff
 Projects
   SERUM
    Internal Documents
 Intern
 Impressum
AG HIS
Jobs / Tasks
Courses
Publications
Contact
Misc
Impressum
(C) AG DBIS
 

"Known Bugs" von Informix

Context Description Example Workaround Status Informix Status Informix Beta Who
SET, SPL, UDR Informix schränkt die Verwendung von Typen als "return value" in SPL Funktionen stark ein (siehe Informix Syntax Guide p. 4-271).  Informix überprüft nicht in allen Fällen, ob Typ erlaubt ist => es kann wärend der Ausführung zu Fehlern kommen. Es darf kein SET in einer SPL Funktion zurückgegeben werden. Die Funktion läuft zwar, aber es kann zu ungewolltem Verhalten (z.B. falsches Ergebnis) führen. Statt SET MULTISET verwenden. Überprüfung nach Duplikation "von hand". Ver: 9.21.UN161 Laut Dokumenation der Beta-Version ist es immer noch nicht erlaubt, SETs in einer SPL-Funktion zurückzugeben.  Wolfgang Mahnke
!!! FIXED in 9.30 !!!

SET, Opaque Types, LVARCHAR
Verwenden von SETs mit LVARCHAR und Opaque Types kann in SPL Funktionen zu Fehlern führen
(392: System error - unexpected null pointer encountered.)
Beim Einfügen in SETs muß Informix überprüfen, dass kein Wert doppelt vorkommt. Dabei scheint Informix Probleme zu haben:
CREATE FUNCTION collection_test() RETURNING MULTISET(LVARCHAR NOT NULL);
 DEFINE set_value SET(LVARCHAR NOT NULL);
 DEFINE return_value MULTISET(LVARCHAR NOT NULL);

 INSERT INTO TABLE(set_value) VALUES("w");
 INSERT INTO TABLE(set_value) VALUES("x");
 INSERT INTO TABLE(set_value) VALUES("v");

 INSERT INTO TABLE(return_value) 
 SELECT * FROM TABLE(set_value);

 RETURN return_value;
END FUNCTION;

SELECT collection_test() FROM TABLE(MULTISET{1});
--392: System error - unexpected null pointer encountered.

Statt SET MULTISET verwenden. Überprüfung nach Duplikation "von hand". Ver: 9.21.UN161
Bug Nr: 940376(closed) + 944863(closed) + 946572
IFMXNr: 127611 (closed????)
Feature Request: 6387
!!! FIXED in 9.30!!!

CaseNr: 240949

IfmxNr: 148064
Wolfgang Mahnke
CDT Laut Informix-Syntax darf bei der Verwendung von TABLE(MULTISET nur noch eine explizit angegebene Menge von Werten folgen (z.B. {1,2,3} ) und kein SQL Statement (z.b. SELECT ...) ACHTUNG: Statement kann verwendet werden, führt aber häufig nicht zum gewünschten Ergebnis (falsche Werte, Server-Absturz etc.). - Ver: 9.21.UN161
Feature Request:
940612
IFMXNr:126009
Laut Beta-Doku immer noch nicht erlaubt. Anfragen auf diese Weise sind immer noch möglich. Wolfgang Mahnke
!!! FIXED in 9.30 !!!

Table Hierarchy, SPL
Ein CAST zum Supertyp einer Tabellenhierarchie funktioniert nicht in einer SPL Funktion, sobald eine Subtabelle mit neuen Attributen existiert. CREATE ROW TYPE a_ty
      ( id integer,
        name varchar(255));
CREATE TABLE a_ta OF TYPE a_ty
       (PRIMARY KEY (id));
CREATE ROW TYPE b_ty 
      (value VARCHAR(255))
UNDER a_ty;
CREATE TABLE b_ta OF TYPE b_ty 
UNDER a_ta;
INSERT INTO a_ta VALUES(1,"aaa1");
INSERT INTO b_ta VALUES(2,"aaa2","www");

CREATE PROCEDURE small_test(value a_ty)
RETURNING a_ty;
RETURN value;
END PROCEDURE;
EXECUTE PROCEDURE small_test((SELECT a::a_ty FROM a_ta a WHERE id=1));
--9636: Opaque type exceeded its maximum length.

- Ver: 9.21.UN161
Bug Nr: 938768
IFMXNr:-
!!! FIXED in 9.30 !!!

CaseNr: 241290

IfmxNr: 148104
Wolfgang Mahnke
UDT, Opaque Type Ein Index auf einem Opaque Type führt bei Anfragen über den Index zu:
-9635   Illegal attempt to convert an opaque type into another type.
Dieser Fehler tritt nur bei bestimmten Anfragen auf. - Ver: 9.21.UN161
Bug Nr: 942483
IFMXNr:129318
Wolfgang Mahnke
!!! FIXED in 9.30 !!!

LVARCHAR, Opaque Type, COLLECTION, ROW TYPE
Dieser Fehler trifft bei ROW TYPEs, die einen LVARCHAR oder einen Opaque Type als Wert beinhalten.
Bei der Verwendung einer Collection of ROW TYPE in einer SPL Funktion kommt es zum Verlust von Daten der ROW TYPE Werte nach dem LVARCHAR, bzw. opaque type.
BEMERKUNG: Es ist noch nicht ganz klar, ob INSERT .. SELECT * ... erlaubt ist.
CREATE ROW TYPE a_ty
(vx VARCHAR(255),
 id INTEGER);
CREATE TABLE a_ta OF TYPE a_ty;
INSERT INTO a_ta(vx,id) VALUES("v1",1);
INSERT INTO a_ta(vx,id) VALUES("v2",2);
INSERT INTO a_ta(vx,id) VALUES("v3",3);
INSERT INTO a_ta(vx,id) VALUES("v4",4);
CREATE PROCEDURE a_test(id INTEGER)
 RETURNING LIST(a_ty NOT NULL)
   DEFINE result LIST(a_ty NOT NULL);
 INSERT INTO TABLE(result) 
  SELECT * FROM a_ta WHERE a_ta.id!=id;
 RETURN result;
END PROCEDURE;

EXECUTE PROCEDURE a_test(1);
(expression)  LIST{ROW('v2',0          ),ROW('v3',0          ),ROW('v4',0          )} 

SELECT a_ta FROM a_ta 
statt 
SELECT * FROM a_ta
ACHTUNG: funktioniert lediglich, falls keine Tabellenhierarchy gegeben ist (siehe Bug 938768)
Ver: 9.21.UN161
Bug Nr: 938767
IFMXNr:-
!!! FIXED in 9.30 !!!

CaseNr: 237734

IFMXNr: 147609
Wolfgang Mahnke
!!! FIXED in 9.30 !!!

ROW TYPE UDR, Typed Table
Eine SQL Anfrage auf einer typisierten Tabelle mit einer Subanfrage auf einer typisierten Tabelle ergibt den Fehler "393: A condition in the where clause results in a two-sided outer" wenn in der Subanfrage 
a) eine UDR mit beiden ROW TYPEs (der Tabellen)
aufgrrufen wird oder
b) die beiden ROW TYPEs direkt miteinander verglichen werden
CREATE ROW TYPE a_ty
(id      int not null,
 val1    lvarchar);
CREATE TABLE a_ta OF TYPE a_ty;
a)
SELECT *
FROM   a_ta a
WHERE  EXISTS(SELECT id FROM a_ta b
              WHERE a=b);
-- 393: A condition in the where clause results in a two-sided outer join.
b)
CREATE FUNCTION testfunction(x a_ty,y a_ty) RETURNING BOOLEAN;
 RETURN 't';
END FUNCTION;

SELECT *
FROM   a_ta a
WHERE  EXISTS(SELECT * FROM a_ta b
              WHERE testfunction(a,b)
);
-- 393: A condition in the where clause results in a two-sided outer join.

a)
Nur die IDs Vergleichen
(gilt nur im SERUM-Kontext)
b)-
Ver: 9.21.UN161
Bug Nr: 943205
IFMXNr:-
!!! FIXED in 9.30 !!!

CaseNr: 237733

IFMXNr: 147606
Wolfgang Mahnke
!!! FIXED in 9.30 !!!

Trigger
Ein CREATE TRIGGER Statement mit einem "TABLE(MULTISET..."  lässt den Server abstürzen. 
Der Fehler tritt nicht auf, wenn  
"REFERENCES ..." weggelassen wird.
 
CREATE TABLE testtable
(name           VARCHAR(50));

CREATE TABLE Project
(name           VARCHAR(50));

CREATE TRIGGER testtrigger 
 UPDATE ON testtable
  REFERENCING OLD AS old
  FOR EACH ROW
  WHEN (2<(SELECT * FROM
  TABLE(MULTISET{3})))
 ( INSERT INTO PROJECT(NAME)   
 VALUES(old.name));

> 25582: Network connection is broken.

In der WHEN Bedingung
ein UDF benutzen, die die Bedingung überprüft.
Ver: 9.21.UN215
Bug Nr: 949663
IFMXNr:-
!!! FIXED in 9.30 !!!

CaseNr: 237726

Dieser Bug soll in 9.30 GA gefixed sein
Wolfgang Mahnke
!!! Kein Bug !!!

GRANT

Im SERUM Kontext vermutlich nicht wichtig!
Als DBA können keine table-level privileges vergeben werden (solange die Tabelle nicht vom gleichen Benutzer erzeugt wurde) -- Do this as user: mahnke
CREATE DATABASE wolfgang_testdb IN data1 WITH LOG;
DATABASE wolfgang_testdb;
GRANT DBA TO expfact; -- another user
CREATE TABLE testtable(id INT, val LVARCHAR);

-- Login as the expfact-user
GRANT SELECT ON testtable TO benutzer
302: No GRANT option or illegal option on multi-table view.
Der Besitzer der Tabelle muss die Rechte weitergeben
oder
GRANT SELECT ON testtable TO benutzer WITH GRANT OPTION AS mahnke
  !!! Kein Bug !!!

CaseNr: 240947

IfxNr: 148049

Geht mit anderer Syntax!
Wolfgang Mahnke
JDBC, Table Hierarchy Es ist per JDBC nicht möglich, einen Tuppel einer getypten Tabelle als ein Objekt zu empfangen, sobald die Tabelle Subtablellen besitzt. Siehe repro (Das Beispiel ist zu gross für diese Tabelle). Die einzelnen Werte des Tuppels auslesen oder Server-Version 9.20.UC2 verwenden   CaseNr: 240945
Documentation Bug 148226 (sieht nicht so aus als wenn dies demnächst unterstützt werden würde)
Wolfgang Mahnke
Weitere Fehler bitte Eintragen ...            
             

 

Abkürzungen

 SPL Stored Procedure Language (eigene Sprache von Informix zur Definition von UDRs).
UDR User Defined Routine (Benutzerdefinierte Funktion, die im DB-Server ausgeführt werden kann).
UDF User Defined Function = UDR
UDT User Defined Type.
CDT Collection Derived Table.
BugNr Von Informix TechSuport München vergebene Nummer
IFMXNr Von Informix (global) vergebene Nummer
CaseNr Von Informix TechSuport (USA) vergebene Nummer
GA General Availability