Exporting to 'INSERT' fails in Oracle SQL Developer - oracle

I run SELECT * FROM tech_rd_fin_sec_rep_drvr and get 20 results.
I go to export these results to 'insert':
However, my exported .sql files looks like the following:
I've done this for four other tables and the same issue happens for each.
This surprises me considering I had done this on this environment with these tables only last week and it worked perfectly.

Related

Oracle's SQL Developer Database Export Results in 2 Digit Years

I'm using Oracle's SQL Developer to export data into CSVs. I found that Oracle spits out the dates as dd-MMM-yy. When I bulk insert these files into SQL Server it's interpreting some of the dates incorrectly. How do I change that?
I'm an Oracle neophyte, so I might be approaching this whole thing incorrectly. I need to transfer a lot of tables/rows from Oracle to SQL Server. I have a linked server set up in SQL to Oracle, but that takes a really long time to transfer the data. About 18 hours, and both databases are on the same server, but it gets the dates correct.
I didn't find any good way to accomplish this other than a couple of PL/SQL scripts I couldn't get to work for me. Is it really that rare that data gets migrated from Oracle to MS-SQL?
Well, dates across database vendors are just hell.
The default date format can be set in SQL Developer Preferences > Database > NLS > Date Format. You can also set it in the session as #belayer has commented.
For writing CSV files or for migration projects, I would always try to control the format directly, like
SELECT id, TO_CHAR(my_date,'YYYY-MM-DD') AS my_date, my_column
FROM my_table;
Having said that, there should be a better way to move the data out of Oracle into SQL Server...

Oracle: How to efficiently copy a table from one schema to another on a different database and server

I have a large table (3.5MM records) that I need to copy from one schema/database to another schema/database. I tried TOAD's copy data from table feature, but got errors and it never fully copied, in part because the connection keeps getting dropped. I'm trying the object copy feature of SQLDeveloper, and after 11 minutes, it's still copying. I tried the SQLPlus COPY statement but got a syntax error (help needed). I'm still open to extracting the data as INSERT statements that I can just run directly.
1) SQLPLUS Copy as follows:
copy from report_new/mypassword#(DESCRIPTION= (ADDRESS=(PROTOCOL=TCP)(HOST=10.15.15.20)(PORT=1541))(CONNECT_DATA=(SERVICE_NAME=STAGE))) to report/mypassword#(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=10.18.22.25)(PORT=1550))(CONNECT_DATA=(SERVICE_NAME=DEV))) CREATE USER_USAGE_COUNT USING SELECT * FROM _USER_USAGE_COUNT
The above gives me
SQL> start copy_user_count_table.sql
SP2-0758: FROM clause missing username
2) I tried TOAD
The TOAD "Copy data to another schema" fails due to the connection getting
dropped. I set the commit threshold first to 5000 then to 500.
3) I'm trying SQLDeveloper's copy function, but I think it's not going to finish anytime soon and it gives me no real progress indications. For all I know, it could be hung but that it just doesn't want to tell me.
4) I thought about creating a datalink, but I don't have the authority to create one, and it's in a corporate environment wherein the DBA's don't respond in under 3 days.
Todo: Should I write my own Java code to just do this one record at a time?? I shouldn't have to do this, but somehow it's easier to send a man to the moon than to copy data from one schema to another.
You can use the copy command of sqlcl which is part of newer SQLdeveloper releases. The sqlcl is found in the Sqldeveloper\bin directory and is named sql.exe (Windows) or sql (Unix/Linux/Mac). The steps to follow are:
Connect to Destination database with sqlcl
sql username/password#destindationdb
Use the copy command
copy from username#sourcedatabase create newtablename using select * from sourcetable;

ORA 30926 - Unable to get stable set of rows in source tables

I recently encountered a Strange issue on Merge statement. It failed with ORA 30926 error.
I have already checked for the below pitfalls,
Duplicate records check in Source and Target table – Came out clean
Source and Target tables Analyze structure – Came out clean
Source and Target tables Indexes Analyze structure – Came out clean
Same Merge SQL when DBA tried in SYS user – Worked. Still Puzzling
Same Merge SQL runs successfully in Copy table of Target – Worked. Still Puzzling
DBA Bounced the TEST server. Though not convincing wanted to give a try as the issue appears to be strange – Didn’t Workout
Gathered the statistics
Truncate the Original target table and reload from Copy table and try the Merge again - Didn't Workout. Failed with same error
Nutshell Script:
MERGE INTO TGT_SCHEMA.EMP T
USING SRC_SCHEMA.S_EMP S
ON
(
T.EMPLOYEE_NO = S.EMPLOYEE_NO AND
T.START_DATE = S.START_DATE
)
Unique Index (EMPLOYEE_NO, START_DATE) exists on Target table and a normal Index of same combination exists on Source table. Target table is a partitioned table and there are some VPD policies applied to other columns.
My Database version : Oracle 11.2.0.3.0
If you really checked everything you said correctly, then this is a bit of a puzzler. I think #4 in your diagnostic checklist may be telling: that the same statement worked when executed as SYS.
For fun, check to see where there are any VPD policies on either table (DBMS_RLS package). If there are, try to disable them and retry the merge.
This error happens on MERGE when the USING clause returns more than one row for one or more target rows according to your matching criteria. Since it can't know which of two updates to do first, it gives up.
Run:
SELECT matching_column1, ..matching_ColumnN, count(*)
FROM (
<your USING query>
)
group by matching_column1, ..matching_ColumnN
having count(*) > 1
To find the offending source data. At that point either modify your USING query to resolve it, change your matching criteria, or clean up bad data - whichever is appropriate.
EDIT - Add another item:
One other possibility - you will get this error if you try to update a column in your target that is referenced in your ON clause.
So make sure that you are not trying to UPDATE the EMPLOYEE_NO or START_DATE fields.

Report driven by SQL Command has stopped working

CR XI Developer R2. Version 11.5.12.1838, talking to Oracle 11.2.0.3 64bit
A report is driven by an SQL Command. It is (necessarily) a complex report consisting of 7 separate SELECT statements UNION ALLed together. The report also starts with a CTE (or whatever they're called in Oracle)
WITH MYCTE AS (
SELECT x, y, z
FROM N)
SELECT ....
The SQL Command was edited thousands of times when under development. It was last changed six months ago.
Now when I edit the SQL Command, (Database Expert - Right click on Command - Edit Command - Close I am greeted by the 'Map Fields' screen
which is telling me that my query doesn't have any columns in it, and well, proceeding further is useless.
It turns out that if the first line of the report is anything other than SELECT ... then this condition occurs. My environment hasn't changed, this report used to work, and now doesn't.
And it's a general thing as well. From scratch I created a report fed by an SQL Command that was
SELECT * FROM DUAL
and it worked fine. Then I created another report fed by an SQL Command that was
/*This is perfectly valid SQL*/
SELECT * FROM DUAL
Result was that no fields were found. I tried again (expecting failure, I wasn't disappointed) with
WITH STUFF AS (
SELECT * FROM DUAL)
SELECT * FROM STUFF
Does anyone know what's going on? I wouldn't mind if SQL Commands didn't support CTEs, but they clearly do, because I managed to create / edit the existing report in the first place ....
Thanks in advance
Wow. It turns out it's a bug in the 11.2.0.3 Version of the oracle client installer. It OLEDb provider correctly. The fix is simply to run
C:\Windows\SysWOW64\regsvr32 <PathToYourOracleClientInstallFolder>\Client32bin\OraOLEDB11.dll
Actually found the answer at https://scn.sap.com/thread/3382251

SAS 9.2 running Oracle query indefinitely

I'm running a pretty large query against Oracle database using SAS for windows 9.2. This query is pretty large where in I wrote a sub-query in WITH clause and used it 4 times. This runs fine on SQL PLUS and SQL Developer, but when i run it using SAS, the program hangs up after 20 mins and I can't even see the log window. I have never worked with SAS and not sure how to proceed but tried following option:
I created a SAS code file and ran it from windows batch file hoping to get log written to windows file system, but even this runs in-definitely and I don't see anything written to log file
Can some one direct me here. How can i use ALTLOG command to get log file written to windows file system so that i can understand the exact error message. By the way DBA's have mentioned that query runs fine and rows are returned from server side, but for some reason SAS program is not able to show this data. I get about 45,000 records from the query.
Thanks
I'll break it into two points:
1) running an existing Oracle SQL query in SAS without ever using SAS:
best way for you is to embed your Oracle SQL code in so called PROC SQL explicit pass-through:
proc sql;
connect to oracle as db1 (user=user1 pw=pasw1 path=DB1);
create table test_table as
select *
from connection to db1
( /* here we're in oracle */
select * from test.table1 where rownum <20
)
;
disconnect from db1;
quit;
(borrowed from my answer to another question Limiting results in PROC SQL)
The point is not to try to translate it to SAS SQL (don't know if you tried or not).
Also make sure you're creating a SAS table (as in the example) from query result, not writing it to SAS OUTPUT window.
2) Regarding getting the log: the log about an action is in general written once it's done, so if the query is really running for a long time, you won't see any intermediate logs.
Anyway, log buffering is the default setting for batch jobs, so log messages are written after the buffer is full.
To get log messages written immediately to the log file set LOGPARM option:
-LOGPARM= “WRITE=IMMEDIATE”
the opposite option is BUFFERED.
To find out the config file(s) used run following in your SAS session:
proc options option=config;run;
Then enter the option above on separate line in the config file.

Resources