Oracle's SQL Developer doesn't display the content of XML columns when the datatype XMLType is used. The first lines are displayed ok (if Preferences > Database > Advanced > Display XML Value in Grid is ticked), but once you doubleclick on the little yellow pencil, the "View Value" window remains empty. Curiously, it works if you store the XML in a clob.
CREATE TABLE t (x XMLTYPE, c CLOB);
INSERT INTO t VALUES (XMLTYPE('<x/>'), '<x/>');
COMMIT;
SELECT * FROM t;
After a lot of internet search, I found a post by thatJeffSmith saying that it's a known bug and will be fixed soon. And yes, it is working again from version 19.1 onwards. However, at work we are stuck with version 18.2 for a while. So, is there a workaround in 18?
Version XML View Value
17.3.0.271 ok
17.4.0.355 ok
18.1.0.095 empty
18.2.0.183 empty
19.1.0.094 ok
19.2.1.247 ok
19.4.0.354 ok (but needs modern JDK)
This is how it looks in 19.1:
Secondly, I couldn't find a list of bugs for SQL Developer, or a list of fixed bugs, or old release notes. Currently, Oracle's download page lists only the latest three releases 19.1, 19.2 and 19.4, so it's impossilbe to find out when this bug was fixed.
The proper solution is an upgrade to version 19 (or theoretically downgrade to 17).
If you are stuck in Version 18, there is a workaround:
SELECT t.x.getClobVal() FROM t t;
For some strange reason, the table alias is required.
Related
I'm trying to get SAP Business Objects to get a report off of a stored procedure. I had no luck, so I'm now just trying with an example/tutorial of how to do it I found online, and I can't get that to work either.
I'm following:
https://irfansworld.wordpress.com/2012/11/17/what-you-should-know-about-stored-procedure-universe-in-bi-4-0/
I created the objects shown in the exact same way, as shown here:
create or replace package emp_package
as type emp_row_type is ref cursor return emp%rowtype;
end emp_package;
/
create or replace
procedure getEmployeesByDepartment
(
return_rows_cursor in out emp_package.emp_row_type,
dept_parameter in emp.deptno%type
)
as begin
open return_rows_cursor for
SELECT *
FROM emp
WHERE emp.deptno = dept_parameter;
end;
/
I get good results back:
Package EMP_PACKAGE compiled
Procedure GETEMPLOYEESBYDEPARTMENT compiled
But here is where I see a glaring difference... For me, it takes what should only be the out/return parameters, and prompts me as if they are input parameters.
Even if i say "OK" to this... it doesn't recognize the fields in the "out" cursor as fields for me to show on the report.
I've even tried changing the cursor paramater from "in out" to just "out"... but still no luck.
Any ideas as to why I can't make this example work for me?
Using SAP Universal Design Tool 4.1.
Oracle 11g
This isn't really an answer, but too long for a comment.
I just tried this with BI4.1 SP Patch 5, and the SP Editor displayed as expected (only showing the DEPT_PARAMETER parameter).
Two possibilities I can think of for the different behavior you're seeing:
One is that there's something going on with the database middleware client that's confusing BO about the parameters. I'm using Oracle 11g client, and an Oracle Native connection in BO (i.e., not ODBC or JDBC). If you're using an ODBC or JDBC connection, try the native client instead.
It might be a bug with the specific version of UDT that you're using. I'd suggest upgrading, or contacting SAP support to see if it's a known issue.
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
I have a field that stores version information such as 1.1, 1.2 etc. However, it will store 4.0 as 4 and 5.0 as 5.
Is there a way to force it to show the .0?
I have tried NUMBER(5, 3) and DECIMAL(5, 3) data types and neither work.
Version - Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
A NUMBER column will never store the decimal value if it doesn't need to.
You can, however, control how the data is displayed to the user when it is converted to a string by using an explicit TO_CHAR rather than relying on implicit data type conversion. If you use the format mask 9.0 in your TO_CHAR call, for example, the string that is generated will always have 1 decimal digit.
SQL> select to_char( 4, '9.0' )
2 from dual;
TO_C
----
4.0
SQL> ed
Wrote file afiedt.buf
1 select to_char( 4.1, '9.0' )
2* from dual
SQL> /
TO_C
----
4.1
That being said, it seems unlikely that you would really want to store software version information in a NUMBER column rather than a VARCHAR2. You, presumably, aren't doing any mathematical operations on the data so most of the benefit of having a NUMBER is off the table. And software versions are not inherently numeric. You often find yourself wanting more than two components (i.e. Oracle 11.2.0.1). And software versions tend to have highly non-numeric things done to them. If the version that follows 4.9 is 4.10, that's very different than the version 4.1 that followed 4.0. If you're using a NUMBER, though, you lose the ability to differentiate between those versions.
If you need to hide this from your code, create a view to hide these details.
It will however, be a string for the same reason Justin indicates.
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 occasionally get this error when i try to update a record through the grid.
One error saving changes to table "SCHEMA"."TABLENAME":
Row 3: Data got committed in another/same session, cannot update row.
Looked up at OTN but no solution yet given.
Tried to disable the option Post edits on row change but still no luck.
There is a known solution for setting the field to NULL through the SQL Worksheet but it's surely a pain.
It could be that your table is created with NOROWDEPENDENCIES so row-level dependency tracking is turned off, and SQL Developer is configured to "Use ORA_ROWSCN for DataEditor insert and update statements".
Either uncheck the ORA_ROWSCN option, or recreate the table with ROWDEPENDENCIES.
Just simply run simple update command and set your cplumn to null. Then try to update with your real value. It will definitely work.
"One error saving changes to table "SCHEMA"."TABLENAME":
Row XX: Data got committed in another/same session, cannot update row."
Got this error with SQL developer when commiting changes in multiple rows,
but not when commiting a single row.
I fixed going to:
Tools menu -> Preferences -> Database -> ObjectViewer
and check: "Post edits on row change"
However, every time I navigate to another row takes some time (less than a second with the DB I am working on).
For what I could understand from other posts the remote DB in my session is being updated (but not comitted to all sessions) every time I change row.
However to commit to all session it is needed to explicitly commit.
Meanwhile I tried, as others suggested, to:
Tools menu -> Preferences -> Database -> ObjectViewer
uncheck "Use ORA_ROWSCN for DataEditor insert and update statements" option
(and also leave uncheck: "Post edits on row change")
This also works, but it is faster.
It guess that now the update is only local. Remote DB is not updated every time I navigate to another row.
It is needed to commit to update remote DB, but now with no errors.
I read that this solution does not worked for all.
It worked in my case with:
SQL developer Version: 17.4.1.054, Build 054.0712
ODAC 12.2c Release 1 and Oracle Developer Tools for Visual Studio (12.2.0.1.0) (32-bit)
(http://www.oracle.com/technetwork/topics/dotnet/utilsoft-086879.html)
Remote DB server version: Oracle Database 11g Release 11.2.0.1.0 - 64bit Production
I ran into this problem as well while running a stored procedure. My solution fell inline with the above answers. Before updating the row that I wanted to the value I wanted, I added an update line that first updated the column to null. The following line then updated the column to the value that I wanted. I did this in addition to unchecking the box for ORA_ROWSCN.
UPDATE TEST_LOCATION SET STATUS = NULL WHERE FULL_NAME = SITE_FULL_NAME;
UPDATE TEST_LOCATION SET STATUS = CAST(STATUS_IN AS INTEGER) WHERE FULL_NAME = SITE_FULL_NAME;