Easily find issues by searching: #<Issue ID>
Example: #1832
Easily find members by searching in: <username>, <first name> and <last name>.
Example: Search smith, will return results smith and adamsmith
Table column data is extracted from the system catalog views ***_TAB_COLUMNS or ***_TAB_COLS. The DATA_TYPE column is allowed to be of null value. In this situation we need to handle the null datatype. This datatype is vital to working with the table, so having a null currently causes NPEs. We should handle nulls by assigning an a value of <unknown> to the datatype.
This will allow for the column to be present in the tree node with <unknown> datatype.
This will allow for the column to be scripted in the DDLs but with <unknown> datatype.
This will allow for the auto completion popup to function correctly.
Oracle datatype extraction has been adjusted so that if a null value is returned from the catalog tables, datatype will be replaced with <unknown> string. This fixes the tree node so that a column with null datatype will display. This fixes the auto completion popup so that the column will display with <unknown> as the datatype. During scripting of the DDL the type will script as <unknown>; a user will have to modify this value for the DDL to work but the column will script.
How to test
// create the following table CREATE TABLE "C##DB_LEFT"."LEG$POZWY" ( "ID" NUMBER(10)NOT NULL, "A" NUMBER(8) NOT NULL, "B" VARCHAR(10) NOT NULL, "C" VARCHAR(20) NOT NULL, "XMLDATA" XMLType NOT NULL, PRIMARY KEY("ID")) GO // discover the object id of this table SELECT object_id FROM DBA_OBJECTS WHERE OWNER = 'C##DB_LEFT' AND OBJECT_NAME = 'LEG$POZWY' // use this object id to modify the system catalog data and set a system datatype column to a non existing object type column. the object id returned was 107421 UPDATE SYS.COL$ SET TYPE# = 123 WHERE OBJ# = 107421 AND NAME = 'C' // The system catalog view will decode this and fail in the only way possible to retreive a none null value for datatype when it attempts to retrieve // a object type that doesn't have an object record. Only other way I think this scenario can be reproduced is through a database version upgrade that could cause this issue in the catalog tables
How to test
// create the following table CREATE TABLE "C##DB_LEFT"."LEG$POZWY" ( "ID" NUMBER(10)NOT NULL, "A" NUMBER(8) NOT NULL, "B" VARCHAR(10) NOT NULL, "C" VARCHAR(20) NOT NULL, "XMLDATA" XMLType NOT NULL, PRIMARY KEY("ID")) GO // discover the object id of this table SELECT object_id FROM DBA_OBJECTS WHERE OWNER = 'C##DB_LEFT' AND OBJECT_NAME = 'LEG$POZWY' // use this object id to modify the system catalog data and set a system datatype column to a non existing object type column. the object id returned was 107421 UPDATE SYS.COL$ SET TYPE# = 123 WHERE OBJ# = 107421 AND NAME = 'C' // The system catalog view will decode this and fail in the only way possible to retreive a none null value for datatype when it attempts to retrieve // a object type that doesn't have an object record. Only other way I think this scenario can be reproduced is through a database version upgrade that could cause this issue in the catalog tables
Issue #14401 |
| Closed |
| Fixed |
| Resolved |
Completion |
| No due date |
| Fixed Build v17.0.4-1, v18.0.0-devi-117 |
| No time estimate |
Oracle datatype extraction has been adjusted so that if a null value is returned from the catalog tables, datatype will be replaced with <unknown> string. This fixes the tree node so that a column with null datatype will display. This fixes the auto completion popup so that the column will display with <unknown> as the datatype. During scripting of the DDL the type will script as <unknown>; a user will have to modify this value for the DDL to work but the column will script.