XML Dateien in ein per XSD Schema erstelltem Dataset speichern

  • C#
  • .NET (FX) 4.0

Es gibt 14 Antworten in diesem Thema. Der letzte Beitrag () ist von OliverSte.

    XML Dateien in ein per XSD Schema erstelltem Dataset speichern

    Hallo,

    Ich habe eine generelle Frag zum Handling von XML/XSD Dateien.
    Vorliegen habe ich eine XSD Schema und viele dazugehörige XML Dateien.
    Diese XML Dateien sollen eingelesen und verarbeitet werden.

    Mein Plan war:
    - Aus der XSD Datei mit dem xsd.exe tool ein Dataset erzeugen
    - Dieses Dataset in Projekt einbinden
    - Entsprechende Berichte/Funktionen etc. die auf diesem Dataset basieren erzeugen

    Die XML Dateien sollten dann direkt in das Dataset eingelesen werden. Durch das XSD Schema würden die XML Dateien zuvor geprüft.

    Mit dem XSD Tool erhalte ich eine .cs Datei (in diesem Fall HarvestedProduction_V3p1.cs)
    Diese Datei habe in mein Projekt unter "Hinzufügen-Vorhandenes Element..." hinzugefügt.
    Diese Datei erscheint dann aber nicht "normales" Dataset:



    Was mache ich hier falsch?

    Danke im voraus!
    Gruß
    Stepper
    eine Xsd-Datei beschreibt die Regeln, nach der eine dazu passende Xml-Datei aufgebaut werden muss.
    Es gibt Xsd-Dateien, die beschreiben die Regeln so, dass ein typisiertes Dataset die Xml-Datei laden kann.

    Es gibt aber Millionen andere Xsd-Dateien, die gänzlich andere Daten-Strukturen beschreiben.

    Man kann sich mit dem Xsd-Tool auch eine KlassenStruktur generieren lassen - welche dann kein typDataset ist. Scheint in deim Fall zuzutreffen.

    Also kurz gesagt: typDatasets benutzen die Xsd-Technologie, und viele andere Daten-Anbieter nutzen sie auch, aber ganz anders.
    Ups - das weiß ich nicht. Ich hab bislang den Dataset-Schalter genommen, wenn ich wusste, dasses ein Dataset war.
    Ich täte eiglich erwarten, dass das Tool streikt, wenn man ihm was ungeeignetes vorsetzt.

    Aber wie's aussieht hauts trotzdem iwelchen Code raus.

    Und nein - wenn der Hersteller seine Daten nicht Datasetmäßig organisiert hat (und das haben die wenigsten), dann kann man kein Dataset draus machen.
    Ich habe mit dem XSD Tool mal Klassen anstatt eines DS erstellen lassen.
    Er zeigt mir jetzt viele Klassen in meinem Projekt an.

    Mir ist jetzt aber grundsätzlich noch nicht ganz klar wie ich auf meine XML Daten konkret zugreife.
    Über

    C#-Quellcode

    1. XmlDocument doc = new XmlDocument();
    2. doc.Load(@"D:\Personen.xml");

    oder mit pathnavigator

    C#-Quellcode

    1. XmlDocument doc = new XmlDocument();
    2. doc.Load(@"D:\Personen.xml");
    3. XPathNavigator navi = doc.CreateNavigator();


    kann ich eine XML Datei einlesen und dann die einzelnen Elemente ansprechen.
    Aber hier komme ich ins schwimmen. Gefühlt würde ich sagen das es möglich sein muss "über das XSD Schema" die XML Dateien einzulesen und das ich dann direkt die Daten im Objekt ansprechen kann so wie bei einem typisiertem Dataset.

    Für diesen Thread wird das aber glaube ich etwas zu Allgemein.
    Vielleicht erzähl ich ja Blödsinn, aber ich verwende Das XSD.exe Werkezug um damit aus XML-Dateien die benötigten *.xsd Dateien zu bauen, um diese in mein jeweiliges Projekt dann als Dataset übernehmen zu können.
    Die *xsd-Dateien liegen dan auf der Festplatte *irgendwo* herum und ich binde sie über "Hinzufügen" / "vorhandenes Element" ins Projekt ein, wobei sich das Visual Studio dann die betreffende Datei ins Projekt kopiert, die fehlenden *.xsc und *.xss erzeugt. Fertig ist das Dataset. Ob die Datentypen jetzt noch bearbeitet werden müssen etc. ist mal eine andere Sache.

    Ich würde also erst mal schauen, ob Deine xsd-Daten nicht bereits ein fertiges Dataset beschreiben, so dass Du diese Datei einfach nur deinem Projekt zufügen musst. Falls nicht, dann nehme halt die XML-Dateien um Dir mit

    Quellcode

    1. xsd.exe meine.xml /d
    einfach das Dataset zu erzeugen.

    Bei den XML-Dateien die ich bekommen habe aus einer Schnittstelle habe ich ohne Probleme die leider fehlende Schemadatei (XSD) erzeugen können, nicht immer wurden die Datentypen den vorgageb entsprechend getroffen. Aber die nachzuarbeiten ist wesentlich einfacher als sich große Datasets selbst komplett nachbauen zu müssen. Einziger Haken bei mehreren XML-Dateien ist, dass Du Dir im VS dann das entgültige DS noch selbstzusammen kopieren musst.

    So schauen bei mir die von xsd.exe erzeugten Schemadateien aus:

    XML-Quellcode

    1. <?xml version="1.0" encoding="utf-8"?>
    2. <xs:schema id="SparepartsDataSet" xmlns="" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:msdata="urn:schemas-microsoft-com:xml-msdata">
    3. <xs:element name="RecordSet">
    4. <xs:complexType>
    5. <xs:sequence>
    6. <xs:element name="PartsData" minOccurs="0" maxOccurs="unbounded">
    7. und so weiter


    Lesen des Dataset:

    C#-Quellcode

    1. DataSet.ReadXML(Dateiname_mit_Pfad);

    Schreiben:

    C#-Quellcode

    1. DataSet.WriteXML(Dateiname_mit_Pfad);


    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „Dksksm“ ()

    stepper71 schrieb:

    Ich habe mit dem XSD Tool mal Klassen anstatt eines DS erstellen lassen.
    Er zeigt mir jetzt viele Klassen in meinem Projekt an.

    Mir ist jetzt aber grundsätzlich noch nicht ganz klar wie ich auf meine XML Daten konkret zugreife.
    Eine Möglichkeit ist XmlSerialisierung.
    Also tatsächlich greifst du auf ühaupt kein Xml mehr zu, sondern der XmlSerializer liest eine Xml in eine geeignete Klassenstruktur (die vom Xsd-Tool generiert wurde).

    Und da kannst du dann direkt auf ordentliche .Net-Objekte zugreifen, und brauchst dich mit Xml ühaupt nicht mehr befassen.
    @Dksksm Danke für deinen Lösungsvorschlag. Habe das mal ausprobiert und es hat soweit funktioniert das ich beim einlesen der erzeugten xsd Datei ein Dataset erhalten habe das auf den ersten Blick sehr gut aussieht!!!
    Soweit so gut.

    Zwei Probleme gibt es aber mit dieser Lösung:
    1. Sobald ich im Programm auf das ds zugreife, bekomme ich die exception: Dieselbe Tabelle 'Address' kann in zwei geschachtelten Beziehungen nicht die untergeordnete Tabelle sein. Habe dazu im Netz gesucht und viele Treffer dazu gefunden die aber meist sehr alt sind und häufig sehr alte NET Versionen betreffen. Laut MSDN soll es sich um ein Entwurfsproblem handeln.... Eine brauchbare Lösung habe ich bisher nicht gefunden

    2. Die verwendete XML Datei enthält eventuell nur eine Teilmenge des gesamten Umfang. Bei der ursprünglichen XSD Datei handelt es sich um eine offiziell herausgegebene Datei die von verschiedenen Herstellern verwendet werden soll. Die XML Datei habe ich von einem der Hersteller, diese muss aber nicht alle Vorgaben der offiziellen XSD enthalten..... Mit jedem neuen Hersteller müsste ich also damit rechnen das neue Elemente enthalten sind die ich bisher nicht berücksichtigt habe.
    Schau dir die XSD im Editor an, ich habe den Verdacht, es könnte die (Sub-)Tabelle 'Address' gleich 2 mal geben.

    Zu Punkt 2, das ist richtig, aber andererseits kann man auch beide XSDs neben einander legen und verlgeichen. Musst Du IMHO sowieso, weil die Datentypen auch nicht immer als das erkannt werden, was die Quelle (Datenbank / XSD) so haben will. Dann kann man auch leicht fehlende Inhalte identifizieren, oft sind es ganze Subtabellen die nicht vorhanden sind.

    Im meinem Fall handelt es sich bei den XML-Dateien immer um Schnittstellenbeschreibungen, mit dem Aufbau eines Datasets im hier verstandenen Sinn hat es nichts zu tun, was man dan merkt wenn es identische Tabellennamen gibt, die es so in einer Datenbank gar nicht geben kann.
    Ich konnte im Editor keine Dopplung feststellen. Dort gibt es die Tabelle Address einmal und im weiteren 2 Verweise darauf.
    Könnte es sein das es an den Beziehungen liegt?



    zu 2. Das wäre natürlich möglich. Vorausgesetzt Punkt 1 funktioniert....
    Dateien
    Hallo,

    an der Stelle habe ich jetzt auch etwas beizusteuern.
    Das xsd.exe Tool ist Teil vom .NET SDK und bei mir z.B. zu finden in
    c:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools\

    Wenn man nun als Ausgangssituation eine Schemadatei (.xsd) hat, wie es beim Fragesteller @stepper71 der Fall war, die vom Visual Studio beim Importieren eben nicht in ein typisiertes DataSet verwandelt wird, benennt man die Datei einfach in *.xml um und gibt ihr dabei gleich einen schönen Namen, den das DataSet dann nämlich erhält.

    Das ist besser, als eine beliebige Beispiel XML Datei herzunehmen, weil in der XSD nicht nur alle Felder, sondern auch die richtigen Datentypen stehen.

    Viele Grüße,
    Oliver

    OliverSte schrieb:


    Das ist besser, als eine beliebige Beispiel XML Datei herzunehmen, weil in der XSD nicht nur alle Felder, sondern auch die richtigen Datentypen stehen.


    Du hast wohl nicht von Anfang an gelesen. So war ja auch der Plan wie Du es hier vorschlägst. @ErfinderDesRades hat in Post #2 beschrieben, warum das nicht in jedem Fall funktioniert.
    @Dksksm ich habe das sehr wohl von Anfang an gelesen.
    Der Themenstarter hat aus seiner xsd, die VS nicht importiert, lediglich eine .cs generieren können (mit /l:vb wäre es ein .vb geworden). Damit kann man nicht so viel anfangen.
    Das XSD Tool generiert "DataSet-fähige" xsd Dateien nur aus xml. Und um das Tool zu überlisten, muss man die xsd schlicht umbenennen.
    Genau das stand hier noch nicht.

    Viele Grüße,
    Oliver