Re: DataSet and serialization is dangerous

From: ABad (anonymous_at_discussions.microsoft.com)
Date: 02/13/05 

Date: Sun, 13 Feb 2005 18:14:51 -0500

Hey Mauricio,

I just got back from a week in Mexico, had some fun.

Ok. I'm going to state some of my observations on this problem, and I
probably can't offer anything else from here on in, but this is my take.
Take it with a grain of salt and if you don't like it then submit another
message to the newsgroup and see if anyone else may have some input.

1. The dataset deserialization is based on XML.
2. The XML that is deserialized could be created by hand, a java client, a
perl client, etc. But the thing to note here is it doesn't have to come from
a dataset! Think interoperability.
3. The diffgram is a stateful data representation, meaning it knows it's
previous state and its current state.
4. Because of 1,2 & 3, the deserialization process is complex, look at the
XmlReadMode enumeration. It has deal with missing schema, conflicting
schemas, constraints, missed match data, etc. Also read about the dataset
merge because ReadXml deserialization is closely related to the dataset
merge.
5. An in memory merge between two datasets is much different than an XML
serialization/ReadXml merge. In memory merge can assume and track much more.
XML can only provide so much when serialized and deserialized, and it was
meant for interoperability. .NET 2.0 will have binary serialization and this
may help you in situations like this.

Now back to your problem.

1. Your server is behind an explicit boundary, where clients send in a
stateful serialized state via XML. Your server can only depend on the
diffgram your clients send in to fully describe what the client had
originally and what was the final outcome of the client's workflow.
2. Your server has no idea about the client's workflow and the number of
deletes that took place. The client could have deleted/added Father1 a 100
times but at the diffgram submittal the server only knows that Father1
existed in the original dataset and Father1 is getting inserted on the
proposed changes.
3. When the client receives a dataset with a row that exists and has a
primary key, the only changes to that row that make sense to the server are:
no changes, modified, or deleted.
4.With all this in mind, go back and take a look at the XML diffgram that
your client is submitting to the server (I've included it below). The
dataset used for deserialization on the server only knows this information
coming in, nothing else. Your diffgram states that Father1 existed
originally but its proposing to insert another Father1.
5. The only thing the dataset, when deserializing, can do in this case is
either not accept the changes or *infer* a delete has taken place and
another row is being inserted with the identical primary key. The dataset
does not do go forward and try to guess that the delete has happened, so it
rejects your changes (I know that it accepts the change to the 2nd column in
the father table but what actually happens is that the merge logic makes the
change to the existing Father1 row but throws away the rest of the changes.
Attach events to the dataset that reads in the XML file and you can see for
yourself.).

So what can your client do?

1. It can send over the delete 1st seperately, and then do the re-insert and
child addition.
2. It could do what I did in my first merge example with the addition of the
primary key, keep the original dataset in memory on the client, and when the
client submittal takes place, merge the dataset with the changes with the
original dataset in memory and submit the changes from the original dataset.
3. It could first check, on additions, if a row with the primary key already
exists but is in a state of deleted. If so bring back the original version
and then continue to make changes to it.

There might be a more elegant solution but I can't come up with one at the
moment. But these solutions, and any other solution, will avoid sending an
XML diffgram with an invalid state shown below in the diffgram.

Good Luck!

<?xml version="1.0" standalone="yes"?>
<diffgr:diffgram xmlns:msdata="urn:schemas-microsoft-com:xml-msdata"
xmlns:diffgr="urn:schemas-microsoft-com:xml-diffgram-v1">
  <NewDataSet>
    <FatherTable diffgr:id="FatherTable2" msdata:rowOrder="1"
diffgr:hasChanges="inserted">
      <FatherCol1>Father1</FatherCol1>
      <FatherCol2>ColChanged</FatherCol2>
    </FatherTable>
    <ChildTable diffgr:id="ChildTable1" msdata:rowOrder="0"
diffgr:hasChanges="inserted">
      <ChildCol1>Father1</ChildCol1>
      <ChildCol2>Child1</ChildCol2>
    </ChildTable>
  </NewDataSet>
  <diffgr:before>
    <FatherTable diffgr:id="FatherTable1" msdata:rowOrder="0">
      <FatherCol1>Father1</FatherCol1>
      <FatherCol2>Col1</FatherCol2>
    </FatherTable>
  </diffgr:before>
</diffgr:diffgram>

Relevant Pages

  • Re: how to export view to display - xml with specific xsd?
    ... Also xp_cmdshell runs on the server, ... SQL Server to a file and open the file in Word on the client machine. ... It opens up a ... XML to be generated in a Word-specific XML format. ...
    (microsoft.public.sqlserver.xml)
  • Re: XML->Dataset->Database
    ... latest configuration information and the server contains completed survey ... special database tables to control the flow of information, and using XML ... based on what needs to be sent to the client, ...
    (microsoft.public.dotnet.general)
  • Re: Arch question.
    ... If you do create seperate xml classes just for webservices ... ' NameInfo and get result as type HelloResult ... >> 1) On the server, I have my server classes that don't consider any xml. ... >> 4) The client has copy of xmldoc classes as needed. ...
    (microsoft.public.dotnet.framework.webservices.enhancements)
  • Re: porting Access to SQL Server --- what to do with the front-end?
    ... They are both server side languages. ... As you state, HTMl, CSS, and javascript on the client ... Requests to the server use HTTP requests which send either URL-encoded ... strings or XML documents. ...
    (comp.databases.ms-access)
  • Re: DataSet and serialization is dangerous
    ... In other words change you client side logic From: ... > The client side XML changes that are being sent to the server are: ... > Do you see the problem in the client side XML changes that you sending to ... You are telling the server that Father1 already ...
    (microsoft.public.dotnet.framework.adonet)