how to keep xml data inside xml

[Guest]

I have created myDataset which has a dataTable.
This data table has a column called "xmlDate".
I have saved the following data to this field.
<zones><zone>india</zone><zone>france</zone></zones>
When I use myDataset.getXml to get the data to do transformation w/xslt then
I found the output data messed up my xmlDate which means
it become html format (not xml format).
so <zones> become less than / greater than encoding format ()...

The xml string is returned is in a string html format, and the xml
data seems to encode all < and > using < and >. So, what I need to do
is to convert that xml file from a string to a xml nodelist so I can access
all the elements.

 

[Rob Schieber]

I have created myDataset which has a dataTable.
This data table has a column called "xmlDate".
I have saved the following data to this field.
<zones><zone>india</zone><zone>france</zone></zones>
When I use myDataset.getXml to get the data to do transformation w/xslt then
I found the output data messed up my xmlDate which means
it become html format (not xml format).
so <zones> become less than / greater than encoding format ()...

The xml string is returned is in a string html format, and the xml
data seems to encode all < and > using < and >. So, what I need to do
is to convert that xml file from a string to a xml nodelist so I can access
all the elements.

Have you tried wrapping your xml in a CDATA section? This should at
least keep your angle brackets from getting encoded.

 

[Jason Kester]

You're making us cry. That is not data. It should never be stored
like that in your database!

create table YourTableZone
YourTableID int not null
ZoneID int not null
go

create table Zone
ZoneID int not null
ZoneName nvarchar(255) not null
go


Now, you can actually use that data for something, and it will be
trivial to pack it back into XML for transport. Never take the lazy
way out. And if you do, NEVER post about it on a newsgroup!



Jason Kester
Expat Software Consulting Services
http://www.expatsoftware.com/

 

[Rob Schieber]

You're making us cry. That is not data. It should never be stored
like that in your database!

IMHO, I don't think there is anything wrong with storing xml data in a
database. If there was something wrong with it, SQL Server 2005
wouldn't have an "XML" datatype.

 

[Jason Kester]

Sql server will also let you name a table [Index] or even [Select].
Just because the technology allows you to do foolish things doesn't
mean you should make a habit of doing them.

Data normalization is a good thing. You shouldn't be breaking it
unless you have a really good reason. Laziness doesn't qualify as a
good reason!

Jason Kester
Expat Software Consulting Services
http://www.expatsoftware.com/

 

[Kevin Spencer]

Some technical information:

XML is great stuff. It is pure text, which makes it
cross-platform-compatible, and a perfect medium for exchanging data between
a potentially great variety of systems. In addition, XML can be a medium for
just about anything you want, from pure text to binary data to processing
code.

That said, XML is not the best medium for everything. To store a number
properly in an XML document, you need a .XSD schema document to specify the
type-mapping of the text data to a specific numeric data type, and an XML
file with a prolog and at least one set of element tags. So, in terms of
storage, you're storing perhaps a 64-bit value in two text documents
comprising upwards of 1KB of space.

Now, a database is designed to store data in an optimal way. It also has a
schema, but that schema applies to the entire database, and all the tables
in it. In the tables themselves, data is stored in binary format. A 64-bit
number occupies 64 bits of storage space. So, obviously, a database is the
best storage device for storing data.

Today we see the marriage of these 2 great technologies, with databases like
SQL Server that can deliver binarily-stored data in "de-compressed" XML
format. So, you can store the data efficiently, and use XML to do with that
data what XML does so well.

Use the right tool for the right job, and you'll go far.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
A watched clock never boils.