Olite10g - CONS-10049 / ORA-00972: identifier too long

While trying to publish an application I get a "CONS-10049 / ORA-00972: identifier too long" error message for tables that have names of 26 or 27 characters long. It looks like it includes the owner/schema name to the length calculation and thinks the table name is exceeding 30 characters. If I remove the tables with these long names the app is built without an error. fyi - The table already exists in an O9iR2 database, I am simply trying to import it for this application.
Any ideas?
TIA,
Scott

Here's the answer:
The max table name length limit is 30 characters. However, OLite prepends 4 characters to the name for an internally used publication item name (i.e. you might see something like clg$<table_name>). Therefore, the actual length limit is 26 characters, not 30. The solution would be to change the table name to be 26 characters or less, or if that is not possible, to create a view on the table and use that for your publication item.

Similar Messages

ORA-00972:identifier too long

hi
oracle up limitation ?
create table aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa(a char);
Error
ORA-00972:identifier too long
or
create table a (aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa char);
Error
ORA-00972:identifier too long
Oracle can not support upto 32 characters table name and field name ?
It is true?
null

If you do a search on the particular Oracle error, you get the following:
ORA-00972 identifier is too long
Cause: The name of a schema object exceeds 30 characters. Schema objects are tables, clusters, views, indexes, synonyms, tablespaces, and usernames.
Action: Shorten the name to 30 characters or less.
It would appear that there's a 30 character limit.
Justin
null

Identifier too long

hi
oracle up limitation ?
create table aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa(a char);
Error
ORA-00972:identifier too long
or
create table a (aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa char);
Error
ORA-00972:identifier too long
Oracle can not support upto 32 characters table name and field name ?
It is true?
null

You have a limitation with table name, constraint name, trigger name, ...
<BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>Originally posted by Liu qing ([email protected]):
hi
oracle up limitation ?
<HR></BLOCKQUOTE>
null

ORA-00972: identifier is too long

Hi All,
I get the error ORA-00972: identifier is too long during installation of NW2004s SR2 Java system with DI. This error is seen on the step Perform post load activites. i have made the changes as suggested by SAP note: 314671. But the error still persists. Can anyone suggest what further more should be done here?
Oracle is unable to delete : OPS$<14 letter host name>\SAPSERVICESR3 and hence the error.
the output from ora_sql_results.log
=============================================================
2008-04-28, 19:04:56 SAPINST ORACLE start logging for
@@SAPDBA_ADDITIONAL.SQL
exit;
Output of SQL executing program:
SQL*Plus: Release 10.2.0.1.0 - Production on Mon Apr 28 19:04:56 2008
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
Connected.
old   3:   :sSchemaUser := upper('&&1');
new   3:   :sSchemaUser := upper('SAPSR3DB');
old 19:   if upper('&&2') = 'NT' then
new 19:   if upper('NT') = 'NT' then
old 21:     :sDomain := upper('&&3');
new 21:     :sDomain := upper('[14 letter Host Name]\SIDadm');
old 32:   elsif upper('&&2') = 'UNIX' then
new 32:   elsif upper('NT') = 'UNIX' then
old 37:     RAISE_APPLICATION_ERROR(-20004,'Invalid OS, must be "NT" or "UNIX": ' || upper('&&2'));
new 37:     RAISE_APPLICATION_ERROR(-20004,'Invalid OS, must be "NT" or "UNIX": ' || upper('NT'));
using following Parameters:
. Schema User:                  SAPSR3DB
. Parametervalue os_authent_prefix:   OPS$
. OPS$SIDADM:                      OPS$[14 letter Host Name]\SIDADM
. SAP SID:                      SR3
. DB SID:                      SID
. R/3 Service User:                 OPS$[14 letter Host Name]\SAPSERVICESR3
. Computer or Domain:                 [14 letter Host Name]\SIDADM
old 119:   if upper('&&4') = 'SYN' then
new 119:   if upper('SYN') = 'SYN' then
old 137:   if upper('&&4') = 'SYN' then
new 137:   if upper('SYN') = 'SYN' then
create synonym: SAP_SDBAH SAPSR3DB.SDBAH
create synonym: SAP_SDBAH SAPSR3DB.SDBAD
unable to delete user: OPS$[14 letter Host Name]\SAPSERVICESR3
begin
ERROR at line 1:
ORA-00972: identifier is too long
ORA-06512: at line 46
Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
SAPINST: End of output of SQL executing program C:\oracle\product\10.2.0\db_1/bin/sqlplus.
SAPINST found errors.
SAPINST The current process environment may be found in sapinst_ora_environment.log.
2008-04-28, 19:04:56 SAPINST ORACLE stop logging
Thanks in advance,
Arun E V

Hi Markus/Stefan,
Thanks for the quick answer. I know i am using a unsupported version, but that should not be a problem here. Though i have not run the installer from the script, still the DB is a successful installation and i have used it like this a few times.
Stefan, I have seen the note and made the required modification but still the issue persists. Is there anything more that i need to do apart from what is mentioned in the note?
The trouble is we are not in a position to change the host name as suggested and would prefer to continue with the same name.
Thanks,
Arun E V

Oracle Connectivity with MS SQL Server. ORA-00972: identifier is too long

I have linked Oracle Database with MS SQL Server using HS and DB Link.
DB Link Script:
CREATE DATABASE LINK "FCHH"
CONNECT TO SA
IDENTIFIED BY <PWD>
USING 'LISTENER_FCHH';
Links tested successfully.
Now "SA" user in Microsoft SQL Server has multiple databases i.e. Master,SecurePerfect,SecurePerfectHistory. when I try following command
select * from "SecurePerfectHistory.DBO.BadgeHistoryTable"@FCHH
ORA-00972: identifier is too long

ORA-00972: identifier is too long
Cause: An identifier with more than 30 characters was specified.
Action: Specify at most 30 charactersAman....

PLS-00114: identifier too long error (Oracle 10g)

Hi All,
Hi All,
I have created procedure called "p_procedure_for_cals_annual_sal_oracle_proprierty.lib".
It is must to give the procedure name as mentioned.(>30 Chars)
But while executing I am getting following error.
SQL> exec p_procedure_for_cals_annual_sal_oracle_proprierty.lib
BEGIN p_procedure_for_cals_annual_sal_oracle_proprierty; END;
ERROR at line 1:
ORA-06550: line 1, column 7:
PLS-00114: identifier 'p_procedure_for_cals_annual_sal_' too long.Please give me suggestion to execute this procedure.
Thank you.
Edited by: user636482 on Mar 22, 2009 9:57 PM

I think you've mistaken EXEC(UTE) with START or @
Execute
Executes a single PL/SQL statement. The EXECUTE command is often useful when you want to execute a PL/SQL statement that references a stored procedure.
Start
STA[RT] {url | file_name[.ext] } [arg...]
Runs the SQL*Plus statements in the specified script. The script can be called from the local file system or from a web server. Only the url form is supported in iSQL*Plus. You can pass values to script variables in the usual way.
Here's a copy/paste of a test:
the file (some_long_name_with_many_characters.sql)
set serverout on
Begin
dbms_output.put_line('A line of text...');
End;
/The SQL*Plus session:
SQL> exec some_long_name_with_many_characters.sql
BEGIN some_long_name_with_many_characters.sql; END;
ERROR at line 1:
ORA-06550: line 1, column 7:
PLS-00114: identifier 'SOME_LONG_NAME_WITH_MANY_CHARA' too long
ORA-06550: line 1, column 43:
PLS-00103: Encountered the symbol "SQL" when expecting one of the following:
<an identifier> <a double-quoted delimited-identifier> delete
exists prior <a single-quoted SQL string>
The symbol "<an identifier> was inserted before "S
SQL> @some_long_name_with_many_characters.sql
A line of text...
PL/SQL procedure successfully completed.
SQL> sta some_long_name_with_many_characters.sql
A line of text...
PL/SQL procedure successfully completed.
SQL>

Identifier is too long error when creating a new summary

I get the following error when trying to create a new summary 'Database Error - ORA-00972: identifier is too long'. Looking at the error message on the web says that the maximum length is 30 char, so I gave it a name of '1', but I still get the error :(
Could someone let me know what goes into the naming 'behind the scenes' as it is obviously using a combination of the given name and something else?

Just for other peoples reference, the problem was due to the size of the name I had given to the db_link that I was using to get to the warehouse. By creating a smaller name for the link, enabled me to get a little further.

PHP - Load Gif image into Oracle Blob field - ORA-00972 error

I am receiving an " ORA-00972 - Identifier Is too Long" error message when I try to update a BLOB field with file contents from a gif file.
__GIF FILES_:_
c:\bl\x_PageLayout-4_LA.gif (15K)
c:\bl\x_PageLayout-4_Spec.gif (21k)
===================================================================================================================================
ORACLE DATABASE (STYLEELEMENTPIX TABLE):*
STYLE_ID NUMBER
SEQ_KEY NUMBER
PIX_NAME VARCHAR2(30 BYTE)
PIX BLOB
PIX_LABEL VARCHAR2(30 BYTE)
MODIFY_DATE DATE
PIX_TYPE CHAR(1 BYTE)
DEFAULTDISPLAY CHAR(1 BYTE)
PIX field currently is null
===================================================================================================================================
PHP CODE:*
$filename = 'C:\BL\\';
$filename .= $row->PIX_NAME; //filename of gif ex: c:\bl\x_PageLayout-4_LA.gif
$fp = fopen($filename, "rb"); //open gif file
$file_content = fread($fp, filesize($filename)); //read gif file
//set gif file in PIX field (PIX datatyle BLOB)
$cursor1 = oci_parse($conn, "UPDATE STYLEELEMENTPIX SET PIX = '$file_content' WHERE STYLE_ID = $row->STYLE_ID AND SEQ_KEY = $row->SEQ_KEY");
oci_execute ($cursor1);
For both records, style id will be 100 ($row->STYLE_ID), and seq_key will be 1 for the first record and 2 for the second ($row->SEQ_KEY)
===================================================================================================================================
ERROR MESSAGE:
Warning: oci_parse() [function.oci-parse]: ORA-00972: identifier is too long in C:\wamp\www\eStyleGuide\Admin\BLOB.php on line 44 ($cursor1 = ....)

Use a LOB locator. See "Inserting and Updating LOBs" on p 193 of the free book http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html
A more concerning issue is the security implications of using string concatenation to construct the SQL statement. It is recommended to use bind variables.

Getting ORA-06512/ORA-00972 ERROR WHILE EXECUTING THE PROCEDURE????

Hi ,
while executing this procedure , I am getting follwoing errors:
Create or Replace procedure ADD_CUSTOM_INDEX is
INDX_NOT_EXIST Number;
CREATE_SQL_STATMENT VARCHAR2(1500);
ALTER_SQL_STATMENT VARCHAR2(150);
CURSOR C1 IS select INDEX_NAME,CREATE_DDL FROM W_CUSTOM_TEST, WC_COMPANY_G WHERE W_CUSTOM_TEST.SYS_TENANT_ID = WC_COMPANY_G.BU_ID;
BEGIN
for V_ROW in C1 loop
     SELECT COUNT(USER_INDEXES.INDEX_NAME) INTO INDX_NOT_EXIST FROM USER_INDEXES WHERE USER_INDEXES.INDEX_NAME = V_ROW.index_name;
     IF INDX_NOT_EXIST = 0 THEN
     CREATE_SQL_STATMENT := ''|| '"'|| V_ROW.CREATE_DDL ||'"' ||'PARALLEL NOLOGGING';
     EXECUTE IMMEDIATE CREATE_SQL_STATMENT;
     ALTER_SQL_STATMENT := 'ALTER INDEX ' ||'"'|| V_ROW.INDEX_NAME ||'"'|| ' NOPARALLEL LOGGING';
     EXECUTE IMMEDIATE ALTER_SQL_STATMENT;
     END IF;
END LOOP;
END ADD_CUSTOM_INDEX;
ERROR at line 1:
ORA-00972: identifier is too long
ORA-06512: at "LOLAP.ADD_CUSTOM_INDEX", line 13
ORA-06512: at line 1.
sturtuce of W_custom_test table is as below:
CREATE TABLE "LOLAP"."W_CUSTOM_TEST"
("INDEX_NAME" VARCHAR2(30) NOT NULL ENABLE,
     "SYS_TENANT_ID" VARCHAR2(15) NOT NULL ENABLE,
"CREATE_DDL" VARCHAR2(1200),
"COMMENTS" VARCHAR2(200),
     "STAT_CD" VARCHAR2(30) DEFAULT 'Active' NOT NULL ENABLE,
     "CREATED" DATE DEFAULT SYSDATE NOT NULL ENABLE,
     "LAST_UPD" DATE DEFAULT SYSDATE NOT NULL ENABLE
Any Pointer??????

Hi
Instead of giving as below, go for the not null constraints.
"STAT_CD" VARCHAR2(30) DEFAULT 'Active' NOT NULL ENABLE,
"CREATED" DATE DEFAULT SYSDATE NOT NULL ENABLE,
"LAST_UPD" DATE DEFAULT SYSDATE NOT NULL ENABLE
That should help
Regards
Sudheer

IMPDP SQLFILE : multibyte characters in constraint_name leads to ORA-00972

Hi,
I'm actually dealing with constraint_name made of multibyte characters (for example : constrain_name='VALIDA_CONFIRMAÇÃO_PREÇO13').
Of course this Bad Idea® is inherited (I'm against all the fancy stuff like éàù in filenames and/or directories on my filesystem....)
The scenario is as follows :
0 - I'm supposed to do a "remap_schema". Everything in the schema SCOTT should now be in a schema NEW_SCOTT.
1 - The scott schema is exported via datapump
2 - I do an impdp with SQLFILE in order to get all the DDL (table, packages, synonyms, etc...)
3 - I do some sed on the generated sqlfile to change every occurence of SCOTT to NEW_SCOTT (this part is OK)
4 - Once the modified sqlfile is executed, I do an impdp with DATA_ONLY.
(The scenario was imagined from this thread : {message:id=10628419} )
I'm getting some ORA-00972: identifier is too long at step 4 when executing the sqlfile.
I see that some DDL for constraint creation in the file (generated at step#2) is written as follow :ALTER TABLE "TW_PRI"."B_TRANSC" ADD CONSTRAINT "VALIDA_CONFIRMAÃÃO_PREÃO14" CHECK ...Obviously, the original name of the constraint with cedilla and tilde gets translated to something else which is longer than 30 char/byte...
As the original name is from Brazil, I also tried do add an EXPORT LANG=pt_BR.UTF-8 in my script before running the impdp for sqlfile. This didn't change anything. (the original $LANG is en_US.UTF-8)
In order to create a testcase for this thread, I tried to reproduce on my sandbox database... but, there, I don't have the issue. :-(
The real system is an 4-nodes database on Exadata (11.2.0.3) with NLS_CHARACTERSET=AL32UTF8.
My sandbox database is a (nonRAC) 11.2.0.1 on RHEL4 also AL32UTF8.
The constraint_name is the same on both system : I checked byte by byte using DUMP() on the constraint_name.
Feel free to shed any light and/or ask for clarification if needed.
Thanks in advance for those who'll take on their time to read all this.
I decided to include my testcase from my sandbox database, even if it does NOT reproduce the issue +(maybe I'm missing something obvious...)+
I use the following files.
- createTable.sql :$ cat createTable.sql
drop table test purge;
create table test
(id integer,
val varchar2(30));
alter table test add constraint VALIDA_CONFIRMAÇÃO_PREÇO13 check (id<=10000000000);
select constraint_name, lengthb(constraint_name) lb, lengthc(constraint_name) lc, dump(constraint_name) dmp
from user_constraints where table_name='TEST';- expdpTest.sh :$ cat expdpTest.sh
expdp scott/tiger directory=scottdir dumpfile=testNonAscii.dmp tables=test- impdpTest.sh :$ cat impdpTest.sh
impdp scott/tiger directory=scottdir dumpfile=testNonAscii.dmp sqlfile=scottdir:test.sqlfile.sql tables=testThis is the run :
[oracle@Nicosa-oel test_nonAsciiColName]$ sqlplus scott/tiger
SQL*Plus: Release 11.2.0.1.0 Production on Tue Feb 12 18:58:27 2013
Copyright (c) 1982, 2009, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> @createTable
Table dropped.
Table created.
Table altered.
CONSTRAINT_NAME                  LB       LC
DMP
VALIDA_CONFIRMAÇÃO_PREÇO13             29         26
Typ=1 Len=29: 86,65,76,73,68,65,95,67,79,78,70,73,82,77,65,195,135,195,131,79,95
,80,82,69,195,135,79,49,51
SQL> exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
[oracle@Nicosa-oel test_nonAsciiColName]$ ./expdpTest.sh
Export: Release 11.2.0.1.0 - Production on Tue Feb 12 19:00:12 2013
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Starting "SCOTT"."SYS_EXPORT_TABLE_01": scott/******** directory=scottdir dumpfile=testNonAscii.dmp tables=test
Estimate in progress using BLOCKS method...
Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
Total estimation using BLOCKS method: 0 KB
Processing object type TABLE_EXPORT/TABLE/TABLE
Processing object type TABLE_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
. . exported "SCOTT"."TEST"                                  0 KB       0 rows
Master table "SCOTT"."SYS_EXPORT_TABLE_01" successfully loaded/unloaded
Dump file set for SCOTT.SYS_EXPORT_TABLE_01 is:
/home/oracle/scott_dir/testNonAscii.dmp
Job "SCOTT"."SYS_EXPORT_TABLE_01" successfully completed at 19:00:22
[oracle@Nicosa-oel test_nonAsciiColName]$ ./impdpTest.sh
Import: Release 11.2.0.1.0 - Production on Tue Feb 12 19:00:26 2013
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Master table "SCOTT"."SYS_SQL_FILE_TABLE_01" successfully loaded/unloaded
Starting "SCOTT"."SYS_SQL_FILE_TABLE_01": scott/******** directory=scottdir dumpfile=testNonAscii.dmp sqlfile=scottdir:test.sqlfile.sql tables=test
Processing object type TABLE_EXPORT/TABLE/TABLE
Processing object type TABLE_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
Job "SCOTT"."SYS_SQL_FILE_TABLE_01" successfully completed at 19:00:32
[oracle@Nicosa-oel test_nonAsciiColName]$ cat scott_dir/test.sqlfile.sql
-- CONNECT SCOTT
ALTER SESSION SET EVENTS '10150 TRACE NAME CONTEXT FOREVER, LEVEL 1';
ALTER SESSION SET EVENTS '10904 TRACE NAME CONTEXT FOREVER, LEVEL 1';
ALTER SESSION SET EVENTS '25475 TRACE NAME CONTEXT FOREVER, LEVEL 1';
ALTER SESSION SET EVENTS '10407 TRACE NAME CONTEXT FOREVER, LEVEL 1';
ALTER SESSION SET EVENTS '10851 TRACE NAME CONTEXT FOREVER, LEVEL 1';
ALTER SESSION SET EVENTS '22830 TRACE NAME CONTEXT FOREVER, LEVEL 192 ';
-- new object type path: TABLE_EXPORT/TABLE/TABLE
CREATE TABLE "SCOTT"."TEST"
   (     "ID" NUMBER(*,0),
     "VAL" VARCHAR2(30 BYTE)
   ) SEGMENT CREATION DEFERRED
PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 COMPRESS FOR OLTP LOGGING
TABLESPACE "MYTBSCOMP" ;
-- new object type path: TABLE_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
ALTER TABLE "SCOTT"."TEST" ADD CONSTRAINT "VALIDA_CONFIRMAÇÃO_PREÇO13" CHECK (id<=10000000000) ENABLE;I was expecting to have the cedilla and tilde characters displayed incorrectly....
Edited by: Nicosa on Feb 12, 2013 7:13 PM

Srini Chavali wrote:
If I understand you correctly, you are unable to reproduce the issue in the test instance, while it occurs in the production instance. Is the "schema move" being done on the same database - i.e. you are "moving" from SCOTT to NEW_SCOTT on the same database (test to test, and prod to prod) ? Do you have to physically move/copy the dmp file ? Hi Srini,
On the real system, the schema move will be to and from different machines (but same DBversion).
I'm not doing the real move for the moment, just trying to validate a way to do it, but I guess it's important to say that the dump being used for the moment comes from the same database (the long story being that due to some column using object datatype which caused error in the remap, I had to reload the dump with the "schema rename", drop the object column, and recreate a dump file without the object_datatype...).
So Yes, the file will have to move, but in the current test, it doesn't.
Srini Chavali wrote:
Obviously something is different in production than test - can you post the output of this command from both databases ?
SQL> select * from NLS_DATABASE_PARAMETERS;
Yes Srini, something is obviously different : I'm starting to think that the difference might be in the Linux/shell side rather than on the impdp as datapump is supposed to be NLS_LANG/CHARSET-proof +(when traditional imp/exp was really sensible on those points)+
The result on the Exadata where I have the issue :PARAMETER                      VALUE
NLS_LANGUAGE                   AMERICAN
NLS_TERRITORY                  AMERICA
NLS_CURRENCY                   $
NLS_ISO_CURRENCY               AMERICA
NLS_NUMERIC_CHARACTERS         .,
NLS_CHARACTERSET               AL32UTF8
NLS_CALENDAR                   GREGORIAN
NLS_DATE_FORMAT                DD-MON-RR
NLS_DATE_LANGUAGE              AMERICAN
NLS_SORT                       BINARY
NLS_TIME_FORMAT                HH.MI.SSXFF AM
NLS_TIMESTAMP_FORMAT           DD-MON-RR HH.MI.SSXFF AM
NLS_TIME_TZ_FORMAT             HH.MI.SSXFF AM TZR
NLS_TIMESTAMP_TZ_FORMAT        DD-MON-RR HH.MI.SSXFF AM TZR
NLS_DUAL_CURRENCY              $
NLS_COMP                       BINARY
NLS_LENGTH_SEMANTICS           BYTE
NLS_NCHAR_CONV_EXCP            FALSE
NLS_NCHAR_CHARACTERSET         AL16UTF16
NLS_RDBMS_VERSION              11.2.0.3.0the result on my sandbox DB :PARAMETER                      VALUE
NLS_LANGUAGE                   AMERICAN
NLS_TERRITORY                  AMERICA
NLS_CURRENCY                   $
NLS_ISO_CURRENCY               AMERICA
NLS_NUMERIC_CHARACTERS         .,
NLS_CHARACTERSET               AL32UTF8
NLS_CALENDAR                   GREGORIAN
NLS_DATE_FORMAT                DD-MON-RR
NLS_DATE_LANGUAGE              AMERICAN
NLS_SORT                       BINARY
NLS_TIME_FORMAT                HH.MI.SSXFF AM
NLS_TIMESTAMP_FORMAT           DD-MON-RR HH.MI.SSXFF AM
NLS_TIME_TZ_FORMAT             HH.MI.SSXFF AM TZR
NLS_TIMESTAMP_TZ_FORMAT        DD-MON-RR HH.MI.SSXFF AM TZR
NLS_DUAL_CURRENCY              $
NLS_COMP                       BINARY
NLS_LENGTH_SEMANTICS           BYTE
NLS_NCHAR_CONV_EXCP            FALSE
NLS_NCHAR_CHARACTERSET         AL16UTF16
NLS_RDBMS_VERSION              11.2.0.1.0------
Richard Harrison . wrote:
Hi,
Did you set NLS_LANG also when you did the import?Yes, that is one of the difference between the Exadata and my sandbox.
My environnement in sandbox has NLS_LANG=AMERICAN_AMERICA.AL32UTF8 where the Exadata doesn't have the variable set.
I tried to add it, but it didn't change anything.
Richard Harrison . wrote:
Also not sure why you are doing the sed part? Do you have hard coded scheme references inside some of the plsql?Yes, that is why I choose to sed. The (ugly) code have :
- Procedures inside the same package that references one another with the schema prepended
- Triggers with PL/SQL codes referencing tables with schema prepended
- Dynamic SQL that "builds" queries with schema prepended
- Object Type that does some %ROWTYPE on tables with schema prepended (that will be solved by dropping the column based on those types as they obviously are not needed...)
- Data model with object whose names uses non-ascii characters
+(In France we use to call this "gas power plant" in order to tell how a mess it is : pipes everywhere going who-knows-where...)+
The big picture is that this kind of "schema move & rename" should be as automatic as possible, as the project is to actually consolidate several existing databases on the Exadata :
One schema for each country, hence the rename of the schemas to include country-code.
I actually have a workaround yet : Rename the objects that have funky characters in their name before doing the export.
But I was curious to understand why the SQLFILE messed up the constraint_name on one sustem when it doesn't on another...

Column Name too long

While loading the data from XML source I am getting following error
ORA-00972: identifier is too long
I understand that some of the Column name are more then 30 char (Oracle Limit) inmy source but I like to know what needs
to be modified in the IKM to pick only first thirty characters of column name in case of column name is more then 30 Char.
The LKM works fine as it take only the first 30 char to create the table name, I think it take that setting from topology manger.
but what need to modify in IKM to take only first 30 char for column name.
I am creating target table on the fly and I dont wanna modify each column name in the target table, It'll be alot of work for me.
Please let me know your thoughts on this.
Thanks

Yes its erroring out for IKM step for creating target table.
The step is ignoring the error on Create Target Table because of following error
972 : 42000 : java.sql.SQLException: ORA-00972: identifier is too long
java.sql.SQLException: ORA-00972: identifier is too long
ofcourse the column name is longer then Oracle limitation that is 30 Chars.
In the next step for inserting data it is also failing because of same error.
LKM steps work fine as it strip the column name longer then 30 char.

SQL Developer Migrate mySQL to 11g gets ORA-00972 due to 30 char name limit

I am running MySQL version 5.5.30 server, SQL Developer 3.0.04 Build MAIN-04.34, and Oracle Enterprise Server 11.2.0.1.0, and using Migrate option to move both data dictionary and data from mysql to Oracle
Most of the steps worked fine using OnLine option: used Capture just fine to generate the repositiory, and Convert generated DDL script just fine in the SQL Developer file folder.
It failed to create users due to privs, but I created them manually: emulation user and also the MYSQL data schema user, after which I took the generated DDL, connected to my Oracle data schema user, and ran the DDL to basically create all the objects. And found out that over 50 tables / column names from MYSQL are longer then 30 char, and thus the generated DDL fails to create objects..
Question - I can manually replace the names with shorter 30 char names, but if I do, my data migration step will not work.
i cannot find references to 'name too long' problem anywhere is SQL Server documentation..
here is the Oracle error example:
Error report:
SQL Error: ORA-00972: identifier is too long
00972. 00000 - "identifier is too long"
*Cause: An identifier with more than 30 characters was specified.
*Action: Specify at most 30 characters.
Creating Primary Key Constraint PRIMARY_1 on table bank_account ...

Hello,
have you tried the offline migration option? Then you can probably modify also the ctl file for the SQL*Loader to reflect your changes in the DDL script. I didn't yet try it out, it was just an idea that came to my mind.
Regards
Wolfgang

ORA-00972 from generated piece of SQL code

Hi - I stepped over this problem while testing a new procedure:
7 WHENEVER SQLERROR exit
8 SELECT 'STOP! Missing refresh group!' " ' FROM DUAL
9 WHERE NOT EXISTS (SELECT refg_name FROM SYS.DBA_REFRESH WHERE rname='Thingy')
10 SELECT 1/(sign(count(*)) FROM (SELECT refg_name FROM SYS.DBA_REFRESH WHERE rname ='Thingy')
I always get an ORA-00972: identifier is too long when I try to run these lines.
But WHERE is there a too long identifier? "STOP! Missing refresh group!" is only 28 characters long.
Somebody got a clue?
Thanks in advance,
Thomas

The suspection is what you are using something like
SQL> SELECT "'STOP! Missing refresh group!' " FROM DUAL
2 /
SELECT "'STOP! Missing refresh group!' " FROM DUAL
ERROR at line 1:
ORA-00972: identifier is too long, isn't it ?
Double-quoted strings are identifiers - and can't have more than 30 symbols.
Use single quotation in strings.
Rgds.

Can't create controlfile ORA-00972

..

ORA-00972: identifier is too long
How can I fix this? 00972, 00000, "identifier is too long"
// *Cause: An identifier with more than 30 characters was specified.
// *Action: Specify at most 30 characters.
make the new control file in /tmp

ORA-00972 - when autoextending a datafile

Hi Guys,
I'm trying to help a client here that needs to put a datafile in auto extend, and when he typed the code he gets this error:
ORA-00972: identifier is too long
Can someone help please?
Regards,
Texas!

Hi again!
That is a very strange problem. It looks like that the problem is a system table with an identifier > 30 characters. In Oracle each identified can only have a maximum of 30 characters. If an identifier is too long ORA-00972 is thrown. This topic is discussed at the following page:
[http://www.dba-oracle.com/sf_ora_00972_identifier_is_too_long.htm]
Unfortunately they have posted no solution to this on the above page.
regards
Edited by: Florian W. on 05.03.2009 14:17
Hi once again!
You may also look here:
[http://www.kuzbass.ru:8086/docs/rdb702/sqlnet/natconn/instab.htm]
In section A.3 Handling 31-Character Object Names this problem is also discussed.
regards again

Olite10g - CONS-10049 / ORA-00972: identifier too long

Similar Messages

Maybe you are looking for