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
Related
So I am new in SQL DEVELOPER tools and I have written a simple select statement like:
SELECT * FROM employee;
it worked fine but there was a yellow warning mark underneath SELECT and I clicked on that and my query changes into the following query:
SELECT "A1"."EMPLOYEE_ID" "EMPLOYEE_ID","A1"."FIRST_NAME" "FIRST_NAME","A1"."LAST_NAME" "LAST_NAME","A1"."SALARY" "SALARY", "A1"."DEPARTMENT_ID" "DEPARTMENT_ID","A1"."MANAGER_ID" "MANAGER_ID","A1"."HIRE_DATE" "HIRE_DATE"
FROM "INTRO_USER"."EMPLOYEE" "A1";
My Quest is what is the difference between these two queries? although their output is the same
The glob * has been expanded to all column of the table. The table name EMPLOYEE is aliased to A1 to make it shorter.
The feature you are seeing is called 'SQL Text Expansion,' and it's setup to allow you to see what your query would look like if you were working with one or more VIEWS.
For example, SELECT * FROM ALL_TABLES is quite complicated. This feature allows you to see what's actually involved when running that SQL.
https://www.thatjeffsmith.com/archive/2014/12/sql-developer-and-a-12c-magic-trick/
There is probably no change or expected delta in the performance or execution plan of the 2 versions of your query.
I'm having some troubles with ODI logs.
I'm trying to get the logs from the Snp_session, using the session number from this:
select <%=odiRef.getSession("SESS_NO")%> from dual
Unfortunately, it's not always right, and actualy it get the wrong session number quite often, like 1 every 10 times.
Is it an expected behaviour, or is there another way to get the right session?
Edit:
Corrected mistyping error
Not sure why this is working at all… Last time I checked (ODI 11g) this syntax required extra = character (passing over output from ODI Substitution API directly). Can you try:
SELECT <%=odiRef.getSession("SESS_NO")%> FROM dual
?
Oracle Forms 10g - 'NULLS' is not accepted.
In program unit(PL/SQL Code) I use NULLS FIRST and its throwing error.
Encountered the symbol NULLS
select line_id
from oe_order_lines_all
where rownum <5
order by line_id NULLS FIRST;
kindly help
I am not familiar with forms, but a simple workaround (if it works) is to modify the order by clause. For example, assuming the line id's are positive, or at least non-negative, you could
order by nvl(line_id, -1)
The flavour of PL/SQL and SQL used in Forms is different and somewhat older than the one available in the database. Being able to run code on the database does not mean it will run without changes in Forms. Analytic functions is an example of a newer SQL feature which is missing in Forms. But you can always put your code into a PL/SQL package in the database and call it from your forms code.
I'm trying to browse an ms-access data base on a mac. Best results so far, I had with using OpenOffice on a Mac like described here.
Now I can see all the tables. But when I try to access the data with selects, I only see 3 lines of the result set and the contents of string columns is only shown with the first letter.
However, somehow I can access all the data:
select count(*) from SomeTable gives me correct row count.
select * from SomeTable where SomeStringCol='SomeWord' returns the
expected row(s)(so the select seems to use more than the first
letter... and select * from SomeTable where SomeStringCol='S'
returns empty result)
Any idea why it is like it is and how to access the full data? (It's not necessary to go with OpenOffice, that was just the best way up to now)
select * from SomeTable where SomeStringCol='S' only selects those rows where the only text in SomeStringCol is the letter 'S'. This is probably unlikely (but not impossible)
You would need to change the query to select * from SomeTable where left(SomeStringCol, 1) ='S' or select * from SomeTable where SomeStringCol like 'S*'
. when I try to access the data with selects, I only see 3 lines of the result set
As mentioned in the comments to the blog post cited in the question, the unlicensed version of that ODBC driver is crippled and will only return 3 rows.
I recently answered a similar question here regarding LibreOffice Base on Linux. The solution was to use the (free) UCanAccess JDBC driver to connect LibreOffice to the Access database. The actual steps would be slightly different for Mac OS X, but the basic approach would be the same.
I finally installed MDB Tool which opened the full DB and allowed me csv-exports.
I have a view whose DDL definition is many thousands of lines long. Part of our CI process is to drop and recreate views from DDL using SQLPlus called from a command line script.
This works for hundreds of views in the database but the very large view is never created in the target schema. I always manually paste the view creation script into Toad and run it manually after the automated process has completed. This is a drag.
There is no meaningful error message from SQLPlus when the large-view portion of the DDL script is run but I suspect that it fails because of it's size.
Is there a "set" command that I can include at the top of my DDL to tell SQLPlus that it's ok to create large views or am I forever doomed to include a stoopid manual step in the otherwise automatic CI process?
Firstly, use the most recent version of SQLPlus. Its been a long time since I had a piece of code that was too large to be executed through SQLPlus. You can use the InstantClient
I'd also look at re-factoring the view. Look at the WITH clause as that is relatively new and, if the view has evolved over a long period, there's a good chance it can be amended to make use of this
Is there an empty line in the view SQL, or does any line have more than 2499 characters? Either one of these may cause SQL*Plus to behave unexpectedly but not actually fail.
If there is an empty line, Oracle will ignore everything before it and try to run everything after it. (This only applies to SQL, not PL/SQL.) For example, if you have an empty line right after the create view line, the query will run:
SQL> create or replace view newline_in_the_middle as
2
SQL> select * from dual;
D
-
X
A line with >2499 characters will be ignored but Oracle will still try to process the statement without it. This can cause problems but may still result in a valid statement:
SQL> create or replace view long_line as
2 select '...[enter 2500 characters]...' asdf from dual union all
SP2-0027: Input is too long (> 2499 characters) - line ignored
2 select '1' asdf from dual;
View created.
You may have to check the script output very carefully to find these issues.