The semantic of our data is case insensitive, so we configure the oracle sessions to be case insensitive:
alter session set NLS_COMP=LINGUISTIC;
alter session set NLS_SORT=BINARY_AI;
Then, to take advantage of indexes we would also want the primary key to be case insensitive as well:
create table SCHEMA_PROPERTY (
NAME nvarchar2(64) not null,
VALUE nvarchar2(1024),
constraint SP_PK primary key (nlssort(NAME))
)
However, this runs into "ORA-00904: : invalid identifier", so I assume it is not possible to use the nlssort() function in the PK definition.
Next attempt was to associate a case-insensitive unique index to the primary key:
create table SCHEMA_PROPERTY (
NAME nvarchar2(64) primary key using index (
create unique index SP_UQ on SCHEMA_PROPERTY(nlssort(NAME))),
VALUE nvarchar2(1024)
);
but this failed too:
Error: ORA-14196: Specified index cannot be used to enforce the constraint.
14196. 00000 - "Specified index cannot be used to enforce the constraint."
*Cause: The index specified to enforce the constraint is unsuitable
for the purpose.
*Action: Specify a suitable index or allow one to be built automatically.
Should I just conclude that Oracle does not support case-insensitive semantics for a PK constraint? This works fine in MSSQL which has a simpler approach in dealing with collations.
We could, of course, create a unique index instead of the primary key, but I wanted to make sure first that the normal way to do this is not supported.
Our oracle version is 11.2.0.1.
As you are on 11.2 you can use a virtual column to achieve this:
CREATE TABLE SCHEMA_PROPERTY (
REAL_NAME nvarchar2(64) not null,
NAME generated always as (lower(real_name)) primary key,
VALUE nvarchar2(1024)
);
Create a unique index to enforce case-insensitive PK:
create table SCHEMA_PROPERTY (
NAME nvarchar2(64),
VALUE nvarchar2(1024),
constraint SP_PK primary key (NAME)
);
create unique index SP_UN on SCHEMA_PROPERTY(lower(NAME));
Related
I need a column which should store more than 4000 characters(to be exact: between 4000 to 8000). And I want that particular column to be a primary key. Since I have dependency in UI end for that particular column to be primary key.
I tried CLOB and varchar(max) but those datatypes doesn't allow primary key property.
Can anyone help me with a proper datatype which can satisfy both conditions?
I'm using Oracle SQL developer 18.3.0.277
You cannot specify a primary key or unique constraint on a CLOB column. If you try then you get the exception:
ORA-02329: column of datatype LOB cannot be unique or a primary key
You can have a composite primary key with two VARCHAR2(4000) columns:
CREATE TABLE table_name (
value_start VARCHAR2(4000),
value_end VARCHAR2(4000),
CONSTRAINT table_name__value__pk PRIMARY KEY (value_start, value_end)
);
Or, from Oracle 12, you can set the system setting MAX_STRING_SIZE to be extended and can use:
CREATE TABLE table_name (
value_start VARCHAR2(8000) PRIMARY KEY
);
However
I would question the design choice of using a VARCHAR2(8000) column as a primary key as you will need to duplicate the (large) column value in all the referential constraints. Instead, make the value UNIQUE and provide a IDENTITY column which can act as the primary key with a one-to-one correspondence to the large string values.
I want to create a table bar with a named foreign key constraint backed by a named index. I would like to do that with an inline definition in the create table DDL statement. When looking at the Oracle 19 SQL Language Reference it looks like Oracle should support doing this inline.
When executing the following statements...
create table foo (
id number not null primary key
);
create table bar (
id number not null primary key,
nick varchar2(16) not null constraint foo_nick_ck unique using index,
foo_id number not null constraint foo_fk references foo using index
);
Oracle will respond with [42000][907] ORA-00907: missing right parenthesis and point at the position just before the using index on the last line. If I remove using index it works (but without index being created of course). I've kept the column nick as an example of where it works to create the backing index inline, but for a unique constraint instead of a foreign key constraint.
I am aware that a workaround is to create the backing index in a separate DDL statement, but I would very much like to have it neat and tidy inline.
I am aware that a workaround is to create the backing index in a separate DDL statement, but I would very much like to have it neat and tidy inline.
Unfortunately the syntax does not exist to create indexes inline.
The USING INDEX clause is syntactic sugar: Oracle creates indexes to enforce Primary Key and Unique constraints regardless of whether we include that clause (*). This is because an index is necessary to Oracle's implementation of unique constraints. But there is no such need for an index to enforce a foreign key, it's just desirable.
(*) Unless there's an existing index on the constrained column(s) which Oracle can use.
As per Oracle documentation:
You can specify the using_index_clause only when enabling unique or
primary key constraints
You cannot specify this clause for a NOT NULL, foreign key, or
check constraint.
I have a table with Col1 and Col2 as a composite primary key pk_composit_key and a unique index that was automatically created for the constraint.
I then altered the table to add new column Col3.
I dropped the pk_composit_key constraint:
ALTER TABLE table_name DROP CONSTRAINT pk_composit_key;
Now, When I tried to insert records I got ORA-00001: unique constraint pk_composit_key violated.
Why am I getting that error?
When the key was dropped why wasn't the unique index dropped automatically?
You mentioned exporting and importing the schema, and if that happened in the environment that showed this behaviour it would explain what you're seeing; at least if you used legacy imp rather than the data pump impdp.
The original import documentation states the order objects are imported:
Table objects are imported as they are read from the export dump file. The dump file contains objects in the following order:
Type definitions
Table definitions
Table data
Table indexes
Integrity constraints, views, procedures, and triggers
Bitmap, function-based, and domain indexes
So the unique index would have been imported, then the constraint would have been created.
When you drop a primary key constraint:
If the primary key was created using an existing index, then the index is not dropped.
If the primary key was created using a system-generated index, then the index is dropped.
Because of the import order, the constraint is using an existing index,so the first bullet applies; and the index is retained when the constraint is dropped.
You can use the drop index clause to drop the index even if it wasn't created automatically:
ALTER TABLE table_name DROP CONSTRAINT pk_composit_key DROP INDEX;
See also My Oracle Support note 370633.1; and 1455492.1 suggests similar behaviour will occur with data pump import as well. I'm not aware of any way to check if an index is associated with a constraint at this level; there is no difference in the dba_constraints or dba_indexes views when you create the index manually or automatically. Including drop index will make it consistent though.
It depends on how unique index was created...below are the various ways and behaviour
1) first create unique index (on the column for which primary key to be defined) and then add the primary key constraint. In this situation your DDL to add the primary key will utilize the existing unique index. So when you drop the primary key it will not drop the index but only primary key. ==> this is your situation I guess...
2) While creating the table you define the primary key OR when you add the primary key when there was no existing unique index for the column(s) on which primary key to be defined, so system will create a unique index and use it for primary key. So in this case when you drop the primary key the unique index will also get dropped.
I have a table with a long value as primary key.
Now i think that oracle by default will create a index on it.And i dont need to
create a index explicityly.
The question is :Is primary key by default indexed by oracle in this case?
Yes, a primary key (or any unique column constraint) will create an index, if there is not already one present.
This is the case for almost all databases. Otherwise the uniqueness constraint cannot be efficiently enforced.
There is a requirement in our application to create the unique primary key which depend on the value of another unique column (ERROR_CODE). But our application is in a geo active active environment (have several active databases which are synchronized using another program).
Therefore even-though we have a unique constraint on this ERROR_CODE field, there is a possibility that each database has a row with a different PK for the same ERROR_CODE. During the database synchronization, this is a problem, because there are some child tables which has the PK stored in one DB and other rows contain the PK stored in other DB. Because of the unique constraint of ERROR_CODE, sync process cannot move both rows to each database (which is also not a good thing to do).
So there is a suggestion to use the hash of the ERROR_CODE field as the PK value.
I would like to know whether we can define a function based Primary key in oracle?
If PK field is "ID",
"ID" should be equal to ora_has(ERROR_CODE).
Is it possible to define the primary key like that in oracle?
In Oracle 10 you cannot do this, but in Oracle 11 you can. You have to create a virtual column, such columns can be used also as primary key:
ALTER TABLE MY_TABLE ADD (ID NUMBER GENERATED ALWAYS AS (ora_has(ERROR_CODE)) VIRTUAL);
ALTER TABLE MY_TABLE ADD CONSTRAINT t_test_pk PRIMARY KEY (ID) USING INDEX;