Andreas Maiers Live Space

 DataSet1.tblAndiRow NewAndiRow = new DataSet1.tblAndiDataTable().NewtblAndiRow();
DataSet1.tblAndiDataTable NewAndiTable = new DataSet1.tblAndiDataTable();
NewAndiRow.teststr = "Hallo Welt";
NewAndiRow.testdec = new decimal(1.2);
NewAndiTable.ImportRow(NewAndiRow);

 

 

DataSet1

.tblAndiDataTable TempInstanceAndiTable = new DataSet1.tblAndiDataTable();
DataSet1.tblAndiRow NewAndiRow = TempInstanceAndiTable.NewtblAndiRow();
DataSet1.tblAndiDataTable NewAndiTable = new DataSet1.tblAndiDataTable();
NewAndiRow.teststr = "Hallo Welt";
NewAndiRow.testdec = new decimal(1.2);
TempInstanceAndiTable.AddtblAndiRow(NewAndiRow);
NewAndiTable.ImportRow(NewAndiRow);

Wenn man diesen Code ausführt findet man am Ende NewAndiRow in NewAndiTable! Nun gehört NewAndiRow nämlich einer echt existierenden Tabelle (TempInstanceAndiTable) an.

(Der Code hier macht wenig Sinn. Er dient rein zur Verdeutlichung der Funktionsweise.)

Wer eine DataRow über einen WS-Call an einen WebService (oder auch z.B. an einen WCF-Service) schicken will wird auf das Problem stoßen, dass eine DataRow nicht serialisierbar ist, da kein Konstruktor für das DataRow-Objekt existiert (serialisierbare Objekte benötigen einen parameterlosen Konstruktor => sonst ist die Serialisierung schlecht möglich.) Ein DataRow-Objekt wird aber über die NewRow()-Methode der dazugehörigen DataTable erzeugt. Bei dem DataTable-DataRow Konzept herrscht eine Komposition (=> die DataRow kann also nicht ohne eine DataTable überleben). Folglich muss man, um eine DataRow serialisieren zu können (um sie beispielsweise an einen WebService schicken zu können) vorher in eine DataTable verpacken. Erst dann kann es los gehen :-)...

Nach einer kurzen Pause (wegen Zeitmangel;-) melde ich mich mal wieder zurück! Vor ein paar Tagen schlug ich mich mit einem Problem beim typed DataSet rum... Prinzipiell bin ich ziemlich begeistert von diesem Gebilde, da es einem eine Unmenge an Arbeit abnehmen kann. Dennoch sind vereinzelt immer wieder Punkte zu finden, welche wohl noch nicht ganz ausgereift sind! Einer davon betrifft die NullValue Property einer Spalte in einer Tabelle eines typisierten DataSets. Wenn die Spalte ein varchar bzw. ein System.String ist scheint alles in Ordnung zu sein, da man NullValue von dem Dafaultwert (Throw exception) auf einen der beiden anderen Werte ( Null, oder Empty ) setzen kann. Handelt es sich bei dem Feld aber nicht um einen String, sondern z.B. um einen System.Decimal sieht die Sache ein wenig anders aus. Wer meint man könnte NullValue hier einfach z.B. auf den Wert -1 setzen hat weit gefehlt. Will man dies tun bekommt man verwunderlich folgende Fehlermeldung:

"Property value is not valid. For columns not defined as System.String, the only valid value is (Throw exception)".

Um dieses Problem umgehen zu können muss man das DataSet (die xsd-Datei) mit einem XML-Editor öffnen. Dann sucht man das Feld, welchem man als NullValue einen speziellen Wert zuweisen will und fügt hier:

msprop:nullValue="Null-Default-Wert"

ein.

Bei meinem Beispiel würde die Spaltenzeile im DataSet folgendermaßen aussehen (ich möchte in dem System.Decimal-Feld "testdec" also NullValue "-1" haben):

<

xs:element name="testdec" ... msprop:nullValue="-1" ... type="xs:decimal" ... />

Auf diese Weise hat testdec bei DBNull nun im DataSet den NullValue -1, wenn es geladen wird. Das Problem ist also gelöst:-)!

Laut Microsoft soll dieser Fehler übrigens in der kommenden Version von Visual Studio (Orcas) behoben sein. Dann kann man diese Option wohl auch komfortabel im Designer einstellen... werden wir sehen :-)!

 

Ton an, genau anschauen und entspannen:-):

 

http://www.youtube.com/watch?v=6gmP4nk0EOE 

 

Echt geil!!!!