Discussions
Categories
- 385.5K All Categories
- 5.1K Data
- 2.5K Big Data Appliance
- 2.5K Data Science
- 453.4K Databases
- 223.2K General Database Discussions
- 3.8K Java and JavaScript in the Database
- 47 Multilingual Engine
- 606 MySQL Community Space
- 486 NoSQL Database
- 7.9K Oracle Database Express Edition (XE)
- 3.2K ORDS, SODA & JSON in the Database
- 584 SQLcl
- 4K SQL Developer Data Modeler
- 188K SQL & PL/SQL
- 21.5K SQL Developer
- 46 Data Integration
- 46 GoldenGate
- 298.4K Development
- 4 Application Development
- 20 Developer Projects
- 166 Programming Languages
- 295K Development Tools
- 150 DevOps
- 3.1K QA/Testing
- 646.7K Java
- 37 Java Learning Subscription
- 37.1K Database Connectivity
- 201 Java Community Process
- 108 Java 25
- 22.2K Java APIs
- 138.3K Java Development Tools
- 165.4K Java EE (Java Enterprise Edition)
- 22 Java Essentials
- 176 Java 8 Questions
- 86K Java Programming
- 82 Java Puzzle Ball
- 65.1K New To Java
- 1.7K Training / Learning / Certification
- 13.8K Java HotSpot Virtual Machine
- 94.3K Java SE
- 13.8K Java Security
- 208 Java User Groups
- 25 JavaScript - Nashorn
- Programs
- 666 LiveLabs
- 41 Workshops
- 10.3K Software
- 6.7K Berkeley DB Family
- 3.6K JHeadstart
- 6K Other Languages
- 2.3K Chinese
- 207 Deutsche Oracle Community
- 1.1K Español
- 1.9K Japanese
- 474 Portuguese
sqlcl copy failing while it works with sqlplus
so, I am trying to copy some data from one database to another, first I was trying with sqlplus, then I had to stop since some tables had blob data, and sqlplus didn't support, then I came to know sqlcl and decided to give a try which worked perfectly for the blob, however some of the tables working before just stopped working complaining the identifier is too long, it seems its considering the schema name together with the table name making it bigger than the allowed 30 chars, for now I am using the old sqlplus to copy these tables but is there way to work around this, without the need to give login permission to the schema user ? I am not a DBA and neither an oracle expert so would appreciate any insights. thanks in advance.
*sqlplus sample
SQL > copy from user/[email protected] to user/[email protected] APPEND SCMHISTORY.TRANSACTION_DATA_ITEMS using select * from TRANSACTION_DATA_ITEMS where rownum < 5;
Array fetch/bind size is 15. (arraysize is 15)
Will commit when done. (copycommit is 0)
Maximum long size is 80. (long is 80)
4 rows selected from [email protected]
4 rows inserted into SCMHISTORY.TRANSACTION_DATA_ITEMS.
4 rows committed into SCMHISTORY.TRANSACTION_DATA_ITEMS at [email protected]
*sqlcl sample
SQL > copy from user/[email protected] to user/[email protected] APPEND SCMHISTORY.TRANSACTION_DATA_ITEMS using select * from TRANSACTION_DATA_ITEMS where rownum < 5;
Array fetch/bind size is 15. (arraysize is 15)
Will commit when done. (copycommit is 0)
Maximum long size is 80. (long is 80)
Statement create table "SCMHISTORY.TRANSACTION_DATA_ITEMS" ("TRANS_NO" NUMBER(12) , "LINE_NUMBER" NUMBER(10) , "QTY" NUMBER(10) , "DESCRIPTION" VARCHAR2(25 CHAR) , "COMMENT" VARCHAR2(50 CHAR) , "RMA" VARCHAR2(25 CHAR) , "SERVICE_CODE" VARCHAR2(2 CHAR) ) failed, error message: ORA-00972: identifier is too long
COPY_DESTINATION_WAS_NOT_CREATED.
Answers
-
So SQLcl says
Statement create table "SCMHISTORY.TRANSACTION_DATA_ITEMS"
which tells you it is incorrectly enclosing all of <schema>.<table> in double quotes rather than
doing "<schema>"."<table>" instead, as expected.
That looks like a bug, of course, but you can try changing your syntax to
1. Drop the schema name if it is not necessary, as in...
APPEND TRANSACTION_DATA_ITEMS using ...
or
2. Do the double quote enclosure correctly yourself, and maybe SQLcl will skip its own processing...
APPEND "SCMHISTORY"."TRANSACTION_DATA_ITEMS" using...
Cheers
-
thanks, that seems to have done it.
-
Out of curiosity, which of the two did you use? Most interesting would be if option (2) worked for you.
Also, please mark the question as answered so others with the same question will know to check here and so any responder can just skip over it.
-
the second option worked.. it looked weird, as the insert results are like this <schema>"."<table>
but it did insert the data at the correct table at the destination database..
option one was not an option as I can not log on with the schema user.
-
the second option worked.. it looked weird, as the insert results are like this <schema>"."<table>
but it did insert the data at the correct table at the destination database..
option one was not an option as I can not log on with the schema user.
-
Interesting and weird but, as I commented earlier, the quoting logic must have a bug in it. We can hope that will get cleaned up in a future release. For now you have confirmed a workaround exists.