This content has been marked as final. Show 27 replies
Hi We are facing a serious issue now in that our functionality no longer works for 11G customers as a result of the .extract being obsoleted for 11G. The report is used for legal submission by various countries in the EU and could result in massive fines for the customers concerned. The bug itself has now been escalated and could result in P1 severity at any point.
We are trying to implement the xmlserialize feature introduced in 11G but hitting issues in its implementation in our code. Is there a contact I could have from your team that I can liaise with directly to explain in detail the problems we are facing and to get some guidance on how to resolve?
Some distinctions here.
Hi We are facing a serious issue now in that our functionality no longer works for 11G customers as a result of the .extract being obsoleted for 11G.The .extract function is not obsoleted by noticed as being deprecated from 11.2 and onwards.
That does not mean that Oracle will remove this functionality from its database immediately.
I suspect that it will work for still some future versions to come.
Furthermore I can name numerous "functions" where stuff is being marked "deprecated/even obsoleted", for example version 8 and onwards, but still works is all database versions up to date.
obsolete is not equal to deprecated
Deprecated is Oracle's statement of direction regarding future versions so people/companies can be preparing for the desupport of those features in future versions.
The bug itself has now been escalated and could result in P1 severity at any point.Its not a bug, on the contrary. Its a performance enhancement.
Is there a contact I could have from your team that I can liaise with directly to explain in detail the problems we are facing and to get some guidance on how to resolve?Of course you can, if you have a support contract via http://support.oracle.com. At any time you can put in a P1 or escalate your request to solve your problem.
Edited by: Marco Gralike on Apr 26, 2012 10:31 PM
I'm also very curious to see what issues you have in replacing extract() method with XMLSerialize() function.
We are doing something that you suggested earlier , if database version = 11g do one way and if not do another way so that it works for 9.20.8 and 10G and 11G.
We got it working for 11G.
We are facing issues with compilation of code in 184.108.40.206 - it doesn't like this:
cursor c_head_11g is
select XMLSerialize(document (select header_xml from je_oecd_audit_data_t))
keeps complaining of a missing expression
how do we resolve this so that the code works not just for 11G.
You have to use PL/SQL conditional compilation, something like this (if I correctly understand your requirement) :
Now, the problem is that conditional compilation is not enabled by default in version < 10.2, but it is available since 220.127.116.11.
CURSOR c_head IS $IF DBMS_DB_VERSION.VER_LE_10_2 $THEN SELECT header_xml.extract('/*').getClobVal() FROM je_oecd_audit_data_t ; $ELSE SELECT XMLSerialize(document header_xml as clob indent) FROM je_oecd_audit_data_t ; $END
Oracle Support can give you the parameter to set in order to use it in 9i.
We are facing issues with compilation of code in 18.104.22.168 - it doesn't like this:I guess you should also address to your customers, that 9.x and 10.1 database versions are NOT SUPPORTED by Oracle anymore (and also some of the 10.2.0.x versions for that matter). If you hit a bug then you will be out of luck regarding support.
If you hit a not-yet-known bug then you will be S- out of luck regarding support -- no matter what version you use. :( That's my long time experience.
I think this is common practice for all software vendors regarding their product life cycle. Desupport notices are made available years in advance, so no reason to moan about it. AFAIK this information is also already available on http://support.oracle.com for versions like 22.214.171.124.0...
We left the .extract method in our code as some of our 10G customers require it, and we are using xmlserialize for our 11G customers.
We noticed however that the table data is pretty printed for one of our 11G customers (they are on 126.96.36.199 (for our other 3 customers who are also on 188.8.131.52 there is no pretty printing).
Why would pretty printing via .extract still work for one customer on 184.108.40.206 - we checked it they are definitely a 11G customer.
Our understanding was the .extract shouldn't work in 11G can you explain it?
Why would pretty printing via .extract still work for one customer on 220.127.116.11For the same reasons that Marco has listed above on this page. The function has been marked as Obsolete. That means Oracle is providing notice that at some point in the future, they could remove the function completely from the product. It means that the function still exists within the product and can be called and used just as it could in earlier versions. In version x.x.x.x far down the road, it may be removed and then any remaining third-party code (yours) that depended upon it would break. Until then, it will continue to work as it does today in future versions of Oracle, without any improvements from Oracle as they are putting those improvements into non-obsolete objects.
Note: I do not work for Oracle nor do I have any knowledge what version x.x.x.x would be should they ever decide to remove it.
I understand what you are saying and thats fine concerning the obsoletion but what i am saying if 2 different customers are both on same version of 18.104.22.168 and running the same code then how can one get pretty printing of the data using ,extract and the other not get pretty printing of the data, can someone explain it?
set serveroutput on;
xslt := XMLTYPE('<?xml version="1.0" encoding="ISO-8859-1"?>
<xsl:transform version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="node() | @*">
<xsl:apply-templates select="node() | @*" />
xml_in := XMLTYPE('<IN><A_VAL>a_val</A_VAL><A_ATTR>a_attr</A_ATTR></IN>');
xml_out := xml_in.transform(xslt).getclobval();
*= YOU SHOULD NOT USE PRETTY PRINT ! =*
- it has a serious NEGATIVE performance impact
- if needed for debugging, open the XML in, for example, Windows Internet Explorer/Firefox/etc
- aka its stupid thing to do...