Dataset to XML string in Compact Framework

[Steven Nagy]

HI,

This all applies to a project in the compact framework (Pocket PC).

I need to convert a dataset object into XML which I will then send out
via TCP.
In a standard app I would do this as follows:

System.IO.StringWriter sw = new StringWriter();
ds.WriteXml(sw);
string xml = sw.ToString();

However the WriteXml method of compact datasets only supports filenames
and XMLWriters.
I DON'T want to write to a file and then read it in again; it would
kill have the devices resources to do so.

So I've been fumbling with the XMLWriter but can't get any XML out of
it. This is what I have in my device project:

TextWriter tw = new StringWriter();
XmlTextWriter xtw = new XmlTextWriter(tw);
ds.WriteXml(xtw, XmlWriteMode.WriteSchema);
// xtw.Flush();
tw.Write(xml);

Any help is greatly appeciated. I'm also going to need the REVERSE code
as well;
ie. From XML back to a DataSet. Schema needs to be included in both
directions.

Many thanks,
Steven Nagy

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,


I have the very same escenario, this is the code I use to persists the DS

StreamWriter stream = new StreamWriter( dstFile, false);
XmlTextWriter reader = new XmlTextWriter(stream);
DataAccess.OrdersDS.WriteXml( reader, XmlWriteMode.WriteSchema);
reader.Close();
stream.Close();

Now, a warning , the file may be large depending of the dataset, that's why
I zip it and then send the zipped file.


cheers,

 

[Steven Nagy]

yeah but thats the problem, I want to avoid using files all together.
Anyway, I got around it. Just needed to tinker with the StringWriter
classes a bit more.

I don't like writing to file because then that means at any given time
there's a copy of the dataset in memory and on disk/memory, taking
twice the space which is a bad thing I think to do on PocketPC.

Thanks anyways.

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

I don't like writing to file because then that means at any given time
there's a copy of the dataset in memory and on disk/memory, taking
twice the space which is a bad thing I think to do on PocketPC.

Well, you now most have two copies in memory of the dataset taking twice
the space , how you improved it?


The above solution has been working in an app over 3 years now, not a single
complain or a problem until now.


cheers,

 

[Steven Nagy]

Hey,

I'm not ditching on your apps or anything! I just think there must be a
better way.

Currently you:
1) Have a (dataset)
2) which you save to a (file)
3) and then read in on a (stream)
4) which you then write to a (string).

Right?
All I'm saying is that wouldn't it be better to:
1) Have a (dataset)
2) which you write directly to a (stream)
3) which you then write to a (string)

Of course when I put it like this, it doesn't seem like such a huge to
have that extra step, however I am guessing that in any PocketPC apps
one should probably minimise ANY steps that speed up the app and reduce
the amount of memory used.

The above solution has been working in an app over 3 years now, not a single
complain or a problem until now.

Its good that your apps are robust, I wasn't complaining about your
app; I've never seen it!

Keep up the discussion, as I am still learning PocketPC stuff and it
all helps.

Cheers,
Steven Nagy

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

Hey,

I'm not ditching on your apps or anything! I just think there must be a
better way.

No offence taken, just trying to help

Currently you:
1) Have a (dataset)
2) which you save to a (file)

2.5) Zip it.

3) and then read in on a (stream)
4) which you then write to a (string)

4) which you then write to a (stream)

Right?
All I'm saying is that wouldn't it be better to:
1) Have a (dataset)
2) which you write directly to a (stream)
3) which you then write to a (string)

It depends of where your critical link is, mine is in the transmition,
usually the data is sent from the field using a cell phone as modem, as you
can imagine this is the most critical part, I need to transfer the least
amount of data possible. That's why the zip step

The other requirement is that I need to store the transferred data for a
couple of days, in case its need to be consulted again or (most of the time)
retransmited , a file for this is super handy, you have the timestamp of
when it was send.

Of course when I put it like this, it doesn't seem like such a huge to
have that extra step, however I am guessing that in any PocketPC apps
one should probably minimise ANY steps that speed up the app and reduce
the amount of memory used.

Yes, indeed but sometimes you have to trade off , like the above case, the
transmition of the data is a one time operation, you better concentrate your
efforts to make the application faster in the diary use.

A VERY GOOD ADVISE: do not use a dataset to store your data, the
boxing/unboxing can kill the performance , use either SQL CE or a custom
class. I improved the overall performance like 300% when I stopped using
dataset in memory to store the data , I'm talking of 3 tables of around 2K
rows each and one with around 10K.

Keep up the discussion, as I am still learning PocketPC stuff and it
all helps.

A very good resource is the compactframework group


cheers,

 

[Steven Nagy]

Ah now you're making sense to me!

Yes you need to zip it before you send it which means you have no
choice about saving to a file.
In our case, our application runs on a wireless network where the
server is on the same network, and we're not talking about passing
thousands of rows every query.
So for us, saving to a file is no necessary, but definately is in your
case.

Thanks for the advice on the dataset thing. We actually have our own
branded designer classes for that sort of stuff. Datasets are a memory
leech even in the standard framework!

Steven Nagy