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 ... |
|
|
|
|
|
|
|
|
|
|
|
|
|