I don’t know whether Im posting to the correct group.  If not I apologize
and ask to be corrected.

Im trying to export a table to either CSV or XML.  Im having the following
issues.
CSV:  This file has a CLOB field.  When entries were made to this field the
<CR> was used in several places.  When
the export code sees that the remaining cong content in field is ignored.
How do I get around this.

XML:  Exporting to XML is fine - as a text file.  When I open the file in a
text reader similar to Notepad I can see everything.
However when I try using an XML reader I get an open open error. When I try
InfoPath I get the following more explanatory error:

The form contains XML that cannot be parsed:
Only one top level element is allowed in an XML document.

Line 49, Position 2
<row>
-^

Here is the data starting at line 47 to 56:
<column>"EditDate"</column>
</columns>
<row>
<SKU>"#1 STAMP"</SKU>
<SKUSuff>"N"</SKUSuff>
<MfgSKU>""</MfgSKU>
<Desc1>"No. # 1 Stamp -Self Ink"</Desc1>
<Desc2>"Stamp # 1"</Desc2>
<Rev></Rev>
<ItemType>"M"</ItemType>
<Div></Div>

Where do I go from here.
TIA
Ben Sprei

Ben


"Easy" one first

XML, as many specifications is open to a bit of abuse. Since ElevateDB's code is intended for export from/import to ElevateDB it doesn't have a proper header line but starts with <columns>. If you open a "proper" XML file you'll generally see a header <?xml version="1.0" encoding="UTF-8" ?>. I think, but I'm not sure that that's the main problem. If you want it to be compliant with your xml reader try wrapping it in

<?xml version="1.0" encoding="UTF-8" ?>
<TableData>
....
....
</TableData>

But it may not work - I just tried here and it failed with the validator telling me there's a problem on line 116

cvs - what version are you on because I sort of remember having this issue a while back and it was fixed. Its the reason I shifted over to using xml for import/export which had the nice side effect of being faster.


Roy Lambert

Ben

If I correct the error at line 116 then its fine with the wrapper.

The bug was this line (found a better on-line validator)


Russell &amp PartnersQ0845 6801650

which should have been


Russell &amp; PartnersQ0845 6801650


Roy Lambert

I tried that and I get this error

Switch from current encoding to specified encoding not supported. Error
processing resource 'file:///C:/Temp/Transfer/InvMa...

<?xml version="1.0" encoding="UTF-8" ?>

BTW Im using 2.16 Build 2

Ben Sprei

"Roy Lambert"  wrote in message
news:9BEA9B3B-15B3-4125-8C40-B388F61DC8F5@news.elevatesoft.com...

Ben


"Easy" one first

XML, as many specifications is open to a bit of abuse. Since ElevateDB's
code is intended for export from/import to ElevateDB it doesn't have a
proper header line but starts with <columns>. If you open a "proper" XML
file you'll generally see a header <?xml version="1.0" encoding="UTF-8" ?>.
I think, but I'm not sure that that's the main problem. If you want it to be
compliant with your xml reader try wrapping it in

<?xml version="1.0" encoding="UTF-8" ?>
<TableData>
....
....
</TableData>

But it may not work - I just tried here and it failed with the validator
telling me there's a problem on line 116

cvs - what version are you on because I sort of remember having this issue a
while back and it was fixed. Its the reason I shifted over to using xml for
import/export which had the nice side effect of being faster.


Roy Lambert

Im attaching a file with the corrected header and footer.   This file
displays nothing.

Ben Sprei

"Roy Lambert"  wrote in message
news:9BEA9B3B-15B3-4125-8C40-B388F61DC8F5@news.elevatesoft.com...

Ben


"Easy" one first

XML, as many specifications is open to a bit of abuse. Since ElevateDB's
code is intended for export from/import to ElevateDB it doesn't have a
proper header line but starts with <columns>. If you open a "proper" XML
file you'll generally see a header <?xml version="1.0" encoding="UTF-8" ?>.
I think, but I'm not sure that that's the main problem. If you want it to be
compliant with your xml reader try wrapping it in

<?xml version="1.0" encoding="UTF-8" ?>
<TableData>
....
....
</TableData>

But it may not work - I just tried here and it failed with the validator
telling me there's a problem on line 116

cvs - what version are you on because I sort of remember having this issue a
while back and it was fixed. Its the reason I shifted over to using xml for
import/export which had the nice side effect of being faster.


Roy Lambert

Ben

>BTW Im using 2.16 Build 2

That will explain the csv problem (I think)

Roy Lambert

Ben


Here's a link to a validator

http://www.xmlvalidation.com/

Firstly you have the same problem I found (I've reported it) where &amp lacks the semicolon at the end so that will bork it anyway

Secondly, and this is why nothing is displayed (at least at this end in my xml viewer) your xml file isn't UTF-8 - its unicode of some flavour. You need to alter the header to UTF-16 from UTF-8. Do that and it views correctly.

I don't know what you're doing this for but remember the export feature is intended to be used with the import feature and is not intended as a general data transfer mechanism. IE its an internal feature and is subject to change. If its going to be something you rely on it might be best to write your own xml save routine - its extremely easy and puts you in control.

Roy Lambert

Dear Roy:
Sorry for bothering you this much.  I did the corrections - ran it thru
XMLValidators and the file still does not open
Im attaching the file with the correction.  When I tried opening in infopath
I get the following error:

The form contains XML that cannot be parsed:
Switch from current encoding to specified encoding not supported.

Line 1, Position 40
<?xml version="1.0" encoding="UTF-16"?>

What does this mean.

As far as the CSV goes which version exports correctly

Ben

"Roy Lambert"  wrote in message
news:346EB9A0-DFFE-4F87-A8FE-85136679F044@news.elevatesoft.com...

Ben

If I correct the error at line 116 then its fine with the wrapper.

The bug was this line (found a better on-line validator)


Russell &amp PartnersQ0845 6801650

which should have been


Russell &amp; PartnersQ0845 6801650


Roy Lambert

Ben

>The form contains XML that cannot be parsed:
>Switch from current encoding to specified encoding not supported.

This is the clue. The file itself contains encoding information, then the header contradicts it. I don't know what's going on at your end but the one you've just sent was ANSI, and the header says unicode, it the opposite from the last one

When you open the file in notepad if you select Save As it will tell you the current (ie loaded) encoding at the bottom, and you can change it if so desired. That's basically what I did last time and this time. Last time I changed the encoding to UTF-8, this time to unicode.

I use an antique version of Delphi (D2006) which doesn't have unicode so can't test to see what's going on under the hood. If its ElevateDB exporting with different encodings you need to report it to Tim but I'd guess it more likely to be something you're doing to add the headers and footers.

>As far as the CSV goes which version exports correctly

I can't remember which version I reported it in, switched over to XML so can't even say if it works now because I don't use it. I sort of remember Tim saying he'd found and fixed the problem but that's as far as it goes

Roy Lambert

Dear Roy:
I really feel bad bothering you this much.
I finally got all the errors corrected.  Now when I try opening with
infopath I get a dialogue box asking for
a form template.  Is that infopath specific or I can open with a different
reader or create a template.  The question
is how.

Ben

"Roy Lambert"  wrote in message
news:5AAC2C96-8D9E-4073-9BD8-E1A1DE5C37CD@news.elevatesoft.com...

Ben

>The form contains XML that cannot be parsed:
>Switch from current encoding to specified encoding not supported.

This is the clue. The file itself contains encoding information, then the
header contradicts it. I don't know what's going on at your end but the one
you've just sent was ANSI, and the header says unicode, it the opposite from
the last one

When you open the file in notepad if you select Save As it will tell you the
current (ie loaded) encoding at the bottom, and you can change it if so
desired. That's basically what I did last time and this time. Last time I
changed the encoding to UTF-8, this time to unicode.

I use an antique version of Delphi (D2006) which doesn't have unicode so
can't test to see what's going on under the hood. If its ElevateDB exporting
with different encodings you need to report it to Tim but I'd guess it more
likely to be something you're doing to add the headers and footers.

>As far as the CSV goes which version exports correctly

I can't remember which version I reported it in, switched over to XML so
can't even say if it works now because I don't use it. I sort of remember
Tim saying he'd found and fixed the problem but that's as far as it goes

Roy Lambert