Have just upgraded from 10.2a02 to 10.2b and am getting the following error when performing a SAVE on XML content for an excel document:
Command: hXMLDocument:save("file", pc-reportfile).
X-NODEREF or X-DOCUMENT SAVE got an error: Attempt to re-declare namespace prefix '' for namespace '' in element 'Workbook'. It is already declared for namespace 'urn:schemas-microsoft-com:office:spreadsheet'. (9082)
I can see which line(s) it moans about:
<Workbook xmlns:html="http://www.w3.org/TR/REC-html40"
xmlns="urn:schemas-microsoft-com:office:spreadsheet"
xmlns:o="urn:schemas-microsoft-com:office:office"
xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet"
xmlns:x="urn:schemas-microsoft-com:office:excel">
And removing one or the other line clears the error. Only the problem then is the file will not open in Excel without manually adding the line back in.
According to MS and a bit of google, the XML strcuture is correct - so I'm assuming that something has changed in the new release.
Any ideas?
Thanks,
Chris
For now I have created a maker in the XML that allows the page to be saved using the SAVE method without errors, and then using a unix command to find and replace the marker with xmlns="urn:schemas-microsoft-com:office:spreadsheet".
Will be logging a support call tomorrow.
Chris
This is a known issue in 10.2B. It has been fixed in 10.2B01 and 11.0.0. Contact Technical support concerning issue W912240013.
Michael
There are two possible workarounds for this:
Remove the code that sets attributes that look like namespace declarations (fore example hNode:SET-ATTRIBUTE("xmns", "uri") or hNode:SET-ATTRIBUTE("xmlns:prefix", "uri")).
An alternative (and more complete) workaround:
1. Change all CREATE-NODE( ) to CREATE-NODE-NAMESPACE( ) calls. The URI used in these new calls will be based on the location of the SET-ATTRIBUTE( ) calls that look like namespace declarations.
2. Replace all X-NODEREF:SET-ATTRIBUTE( ) calls that do NOT look like namespace declarations with a X-DOCUMENT:CREATE-NODE-NAMESPACE(handle, uri, qualified-name, "attribute"), X-NODE-REF:NODE-VALUE assignment and then a X-NODE-REF:SET-ATTRIBUTE-NODE( ) call. Again, the uri used in the these calls will be based on the location of the SET-ATTRIBUTE( ) calls that look like the namespace declarations.
3. Remove all SET-ATTRIBUTE( ) calls that look like namespace declarations.
An example showing this process is attached.
It has been fixed in 10.2B01 and 11.0.0.
Any details about release dates? For both? :-)
Thanks for the update, I've got a call in with support also so will see what comes of that.
I rewrote it using SAX and this seems to have worked, just need to confirm with some futher testing though.
Chris
10.2B01 will be released in a bit.
11.0.0 will be released later.
:-(
I have also an issue - I have progress 10.2a and I'm trying to load a XML file but I got this error:
Contact System Administrator if you require more information
X-NODEREF or X-DOCUMENT LOAD got an error: FATAL ERROR: file '....SP5.xml', line '146753', column '5', message 'An exception occurred! Type:RuntimeException, Message:operator new fails. Possibly running Of memory'. (9082)
ERROR: Unknown file format:.
Contact System Administrator if you require more information
I tryied several times and allways it says that my error is after line 140000. I don't know if this is a limit or not.
Any help is welcomed.
Thank you very much.
140,000 lines isn't a specific limit, but it does sound like a huge file. How big is the file?
There is a general rule of thumb that a DOM tree will be in the neighborhood of 10 times the size of the serialized XML document. This is subject to the complexity of the document. The more elements, the more nodes in the tree. The more nodes, the more memory.
Michael
around 400.000 lines - it's a XML file of 16 mb ad allways it's stop after 140.000 lines .
That's why I thought that it is a limit. Before I had progress 10.1d and recently I upgrade to 10.2a. I though that my pb will be solved - that wiht the new parser from 10.2a will Ok but still have this error.
Thank you very much for your help.
You may want to try using the SAX interface. It's the alternanative when DOM trees take up too much memory.
The support case confirmed it as bug ref OE00194275, which is fixed in 10.2B01. We have rewritten most of our XML stuff with the SAX writer as a permenant fix, which suits me as it seems easier to code and follow.
Thanks for the help with this one.
Chris
Thank you.
I'll try with the new version and let you know.