SQL->XML->SQL

[dizzy]

Moin!

Folgendes muss ich realisieren: Eine Delphi-Anwendung ermittelt aus einer Tabelle einer SQL-DB ein paar Datensätze, die bestimmten Kriterien entsprechen. Diese muss ich nun SO in eine XML-Datei verpacken, dass ich sie mittles eines .NET-Datasets (im Compactframework) als Datenquelle verwenden kann. Dort werden dann Felder der Datensätze vom User befüllt, und nun soll meine Delphi-Anwendung diese geänderten Daten aus dem XML-File in die lokale DB wieder einpflegen.

Meine Frage ist nun: Wie erzeuge ich aus, z.B. einer Table, ein XML-File welches wie o.g. verwendbar ist? Bzw. wie kann ich selbiges auch in Delphi wieder einlesen?

Ich habe nun so Dinge wie TXMLTransformProvider u.a. gefunden, aber aus der Hilfe zu denen wird mir mal so überhaupt garnicht klar, was die Dinger können, und wie sie im groben eingesetzt werden, und ob sie mir überhaupt bei meinem Problem weiter helfen :stupid:.


\\Edit: Das ganze sieht mir reichlich komplex aus... Ich bin schon kurz davor es dann doch mit CSV-Files zu machen, und diese dann zu parsen. Die Funktion für die ich das brauche ist ja eher eine Zugabe zu einem Programm - das sollte jetzt nicht wer weiss wie generisch und perfekt sein - nur funktionieren :D.

[mschaefer]

Moin, moin,

erfreulicherweise haben sich an sowas schon andere ihre Zähne angelegt:

XMLDataSet

Der XMLDataset wird verwendet, um den Inhalt eines Datensatzes in XML umzuwandeln, damit die Daten zwischen zwei Remoteanwendungen ausgetauscht werden können. XMLDataset wandelt den Datensatz in XML derart um, daß der Datensatz am Zielrechner rekonstruiert werden kann.

Grüße // Martin

[dizzy]

Danke dir schonmal! Ich schau's mir morgen im Büro gleich mal an. Ist das produzierte XML-File dann nur wieder von dieser Kompo lesbar, oder kann ich da mit einem .NET-Dataset auch dran gehen? (Bzw. was muss ich tun, damit eben dies funktioniert?)

[mschaefer]

Die Komponente kann ihre eigene Struktur wieder lesen. Im Prinzip mü´te die auch an Net anzupassen sein. Letzlich hängen dahinter ja nur Fileoperationen. Die Ableitung der Komponente muß dann nochmal überarbeitet werden...

Bis morgen // Martin

[dizzy]

Ich habe das Teil nun mal angefasst, und konnte es leider schon nicht installieren. Zunächst meinte es die vcl50 zu brauchen (ich habe D7), und im 2. Anlauf kannte er an einer Stelle den Bezeichner "Null" nicht, der einem Variant zugewiesen werden soll. Ändern in "nil" brachte nur den neuen Fehler dass Variant und Pointer inkompatibel sein :D.
Der Beschreibung nach habe ich allerdings so meine Bedenken ob ich .NET die erzeugte Struktur mal eben beibringen kann, zumal dazu wie ich gelesen habe diverse Files nötig wären, die diese erstmal beschreiben.
In Anbetracht des geringen Umfangs der Funktion im Gegensatz zum Aufwand dies mit XML zu machen (für mich, da ich sehr wenig von XML weiss), werde ich dann wohl doch ein proprietäres oder CVS-basiertes Format zum Austausch benutzen.
Danke dir trotzdem für den Link und den guten Willen :).

[mschaefer]

Moin, etwas Grübel,

gut das dies kein Net-dpk ist war eigentlich zu erwarten, also geht die dpk Installation natürlich nicht.
Nimm einfach Menü: Komponente Unterpunkt Komponente installieren. Eventuell definierst Du Dir hier ein
eigenes Package. Das sollte gehen, den ich habe ja auch kein D5 und daher ist das dpl-File für mich auch nichtig.

Sonst ist die Komponente einfach von TComponent abgeleitet. Das fürfte die Vcl-für Net daher mitmachen. Als Eigenschaft hat Sie dann auch eine Dataset-Property, dass ist auch nur VCL. Würde mir das Thema Komponenteninstallation nochmal anschauen.

Der Clou der Komponente ist ja gerade, dass man nicht sich selbst mir der XML-Struktur herumschlagen muß, sondern den DataSet angibt und die Komponente daraus eine XML-Struktur beim Speichern in ein Textfile aufbaut.

Grüße // Martin

[mschaefer]

Das Variant-Problem:

Bei Varianten gab es von D5 bis 2005 doch einige änderungen. Unter D& geht das Zuweisen eines Null-Wertes an eine Variante so:

Null( Variante );

Grüße // Martin

[shmia]

Zitat:

Zitat von dizzy

Ich habe das Teil nun mal angefasst, und konnte es leider schon nicht installieren. Zunächst meinte es die vcl50 zu brauchen (ich habe D7), und im 2. Anlauf kannte er an einer Stelle den Bezeichner "Null" nicht, der einem Variant zugewiesen werden soll. Ändern in "nil" brachte nur den neuen Fehler dass Variant und Pointer inkompatibel sein :D.

Du hättest wahrscheinlich die Unit Variants einbinden müssen, damit D7 den Wert Null kennt.
Viele/Alle Funktionen & Konstanten, die sich auf den Datentyp Variant beziehen wurden mit Delphi6
von der Unit System -> Unit Variants ausgelagert.

[dizzy]

Zitat:

Zitat von mschaefer

gut das dies kein Net-dpk ist war eigentlich zu erwarten, also geht die dpk Installation natürlich nicht.

Ne, da hast du mich falsch verstanden. Ich habe nicht D2005, sondern D7! Ich brauche nachher nur ein XML-File, dass ich dem im .NET vorhandenen DataSet anbieten kann.

Zitat:

Zitat von mschaefer

Der Clou der Komponente ist ja gerade, dass man nicht sich selbst mir der XML-Struktur herumschlagen muß, sondern den DataSet angibt und die Komponente daraus eine XML-Struktur beim Speichern in ein Textfile aufbaut.

Und da ist das Problem: Ich werde das XML-File nachher eben NICHT mit dieser Kompo auslesen können, da dies auf einem PocketPC via .NET geschehen soll. Und dort muss ich erst mitteilen, wie das File strukturiert ist. Da ich mich aber faktisch garnicht mit XML-Spezifikationen auskenne, ist das allein schon ein Hindernis für mich.

Zitat:

Zitat von shima

Du hättest wahrscheinlich die Unit Variants einbinden müssen, damit D7 den Wert Null kennt.
Viele/Alle Funktionen & Konstanten, die sich auf den Datentyp Variant beziehen wurden mit Delphi6
von der Unit System -> Unit Variants ausgelagert.

:wall:, okay das leuchtet ein. Danke für den Hinweis!

[rwachtel]

Kannst Du für Deine Aufgabenstellung nicht einfach das TClientDataSet verwenden?

[dizzy]

An welcher Stelle? Also in wie fern?

[rwachtel]

Na, um eine XML-Ausgabe zu erzeugen.

[dizzy]

Das geht? Ui, das muss ich mir dann aber mal genauer anschauen!

Ich habe vorhin noch die Idee gehabt dem PocketPC (Win2003 Mobile SE) einen SQL Moblie zu spendieren, und auf den aus Delphi heraus über WLAN zuzugreifen. Damit ließe sich das Problem mit XML und der Dateiübertragung komplett umgehen. Weiss zufällig einer ob damit eine Kommunikation wie mit jedem anderen SQL-Server via TCP/IP möglich ist? Damit wären dann nämlich 2 Fliegen mit einer Klappe geschlagen!

[Robert_G]

Zitat:

Zitat von dizzy

Das geht? Ui, das muss ich mir dann aber mal genauer anschauen!

Ich habe vorhin noch die Idee gehabt dem PocketPC (Win2003 Mobile SE) einen SQL Moblie zu spendieren, und auf den aus Delphi heraus über WLAN zuzugreifen. Damit ließe sich das Problem mit XML und der Dateiübertragung komplett umgehen. Weiss zufällig einer ob damit eine Kommunikation wie mit jedem anderen SQL-Server via TCP/IP möglich ist? Damit wären dann nämlich 2 Fliegen mit einer Klappe geschlagen!

Ein ein paar cm großer DB-Server? Krank! :mrgreen:

Erste Frage: Wie wichtig ist dir dieser Teil? "...Eine Delphi-Anwendung..."

Ich würde dir vorschlagen das ganze über einen Middle tier zu lösen.
Den Datenzugriff kapselst du in einen WebService (Das ist *viel* einfacher als es klingt. ;) ).
Jetzt brauchst du nur noch aus seinem WSDL-Dateichen die client proxies für deinen CF / .Net Client anlegen lassen.
Du wirst wahrscheinlich einen Großteil des Codes für CF und .Net Client teilen können.
Wobei dank des WebServices sowieso nicht viel Code auf dem Client bleiben wird und es somit auch weniger Zickereien mit dem Mini gibt. :)

Nachtrag: Auch wenn das Ding XmlWebService heißt, solange du kein sophisticated custom serializing, oder andere fortgeschrittene Dinge machst, wrist du an keinem Punkt direkt mit Xml zu tun haben. ;)
Ein Aufruf einner Methode des Proxies wird die eine gefüllte Collection deine Daten zurückliefern, die du zum Bleistift direkt an eine ComboBox packen kannst. ;)

[dizzy]

Zitat:

Zitat von Robert_G

Ein ein paar cm großer DB-Server? Krank! :mrgreen:

Nicht ganz so krank, wenn man bedenkt dass diese DB im Schnitt eine Tabelle mit max. ~50 Datensätzen enthalten wird ;)

Zitat:

Zitat von Robert_G

Erste Frage: Wie wichtig ist dir dieser Teil? "...Eine Delphi-Anwendung..."

Es wäre das eleganteste, da diese Funktion in ein bestehendes großes Projekt eingepflegt werden soll.

Zitat:

Zitat von Robert_G

Ich würde dir vorschlagen das ganze über einen Middle tier zu lösen.
Den Datenzugriff kapselst du in einen WebService (Das ist *viel* einfacher als es klingt. ;) ).
Jetzt brauchst du nur noch aus seinem WSDL-Dateichen die client proxies für deinen CF / .Net Client anlegen lassen.
Du wirst wahrscheinlich einen Großteil des Codes für CF und .Net Client teilen können.
Wobei dank des WebServices sowieso nicht viel Code auf dem Client bleiben wird und es somit auch weniger Zickereien mit dem Mini gibt. :)

Nachtrag: Auch wenn das Ding XmlWebService heißt, solange du kein sophisticated custom serializing, oder andere fortgeschrittene Dinge machst, wrist du an keinem Punkt direkt mit Xml zu tun haben. ;)
Ein Aufruf einner Methode des Proxies wird die eine gefüllte Collection deine Daten zurückliefern, die du zum Bleistift direkt an eine ComboBox packen kannst. ;)

So. Bahnhof :stupid: Ich habe etwa 20% von dem verstanden was du da geschrieben hast :D. Aber trotz meiner Unwissenheit, klingt das alles viel zu "overkill" für ein Mal in der Woche 50 Datensätze auf ein PocketPC zu schieben, und um einen Wert verändert wieder zurück :gruebel:
Eben weil es im Grunde nur um eine solche Kleinigkeit geht, bin ich sehr bemüht eine Lösung zu finden die einfach nur einfach sein soll, weil ich keinen Grund sehe mich extra nur dafür in was weiss ich für Themengebiete reinzulesen ;). Diese Kleinigkeit ist dem Kunden allerdings schon wichtig. Im Klartext: Es geht zum Zählerstandsablesungen die nicht automatisiert stattfinden können. Dazu soll dem Mitarbeiter auf Knopfdruck eine Wunschliste mit (in der Desktop-DB vorhandenen) Messstellen auf sein Handheld geschoben werden. Zu jedem dieser Einträge kritzelt er nun vor Ort die abgelesenen Werte, und im Büro zurück auf Knopfdruck sollen diese Datensätze wieder in die Desktop-DB eingepflegt werden. Gaaaanz simpel. Das System muss nicht mal groß erweiterbar sein :D.

[mschaefer]

Moin, Deepmoin,

Ja mehr als 20% muß man da auch nicht verstanden haben. Ja einige Pocket-PC´s haben die Leistung eines abgespeckten Star-Trek Computers und da ist Middle-Ware natürlich sogar eine Nummer zu klein. Für unsere irdische Pocket-PC-Technik tut es diese triviale simple und chicke XML-Komponente. Wenn das mit dem Installiren der Komponente nicht klappt, dann läßt man es eben! Nimmt die Unit dann im Raw-Mode und kurzum: Simples Beispiel, einfache Komponente, eben mal codiert und: Voilà ! So und jetzt ist Zeit für´n Tee...

Grüße // Martin

[dizzy]

Okay, damit lässt sich in der Tat sehr einfach ein XML-File erzeugen. Aber leider - und das habe ich befürchtet - kann ich in einem .NET-Dataset nichts mit diesem File anfangen. Und darum geht es ja! Es reicht nicht irgend ein XML-File dass ich mit selber Kompo wieder einlesen kann, sondern ein völlig anderes System muss damit zurecht kommen. Und es kommt noch dicker: Der umgekehrte Weg muss auch gehen! D.h. ich muss in meiner CF.NET-Anwendung (die ich mit C# schreibe) ein XML-File erzeugen, dass ich in Delphi wieder einlesen und verwursten kann.

Folgendermaßen habe ich das (augenscheinlich existierende und plausibel gefüllte) XML-File in ein DataGrid in C# zu bekommen:

Code:

DataSet ds = new DataSet();
ds.ReadXml("C:\\Projekte\\DSK Zaehler\\trans.xml", System.Data.XmlReadMode.Auto);
dataGrid1.SetDataBinding(ds, "test");

Und in der 2. Zeile schmeisst's mich mit:

Zitat:

Eine nicht behandelte Ausnahme des Typs 'System.InvalidCastException' ist in system.data.dll aufgetreten.

Zusätzliche Informationen: Die angegebene Umwandlung ist ungültig.

raus. Es fehlen ihm vermute ich die Schema-Files (was immer da wie drin stehen muss). Zudem bleibt bei der Lösung mit einer Datei im Austausch das Übertragungsproblem zum Handheld :?

Wie ist das denn mit dem SQL Mobile? Geht das wie gewohnt einfach via IP+Port+Name+PW anmelden, und schreiben und lesen wie gewohnt? Die Geräte sind heute erst bestellt, daher kann ich das noch nicht selbst testen, wüsste aber gerne im Vorhinein ob ich mich erneut vor einer Betonwand befinde :stupid:.

[mschaefer]

Da ich kein NET in D6 habe muß ich mir darüber auch weniger Gedanken machen :mrgreen: .

Eine allgemeine Vorraussetzung ist für die Komponente, das ein und die gleiche Datenbankstruktur der Tabelle im angeschlossenen DataSet schon existiert. Und das hat nichts mit NET zu tun. Also wichtig ist, dass die Komponente nur eine vorhanden DB-Struktur mit Daten füllt. Sie legt keine Struktur im DataSet an. Das andere ist wohl eine WLAN-Thematik und fordert einen neuen Thread.

Versuche mal die Paradoxtabelle mit einer Netanwendung zu laden. Im zweiten Schritt dann die XML-Komponente an diese Netwanwendung anzuflanschen.

Grüße // Martin

[dizzy]

Zitat:

Zitat von mschaefer

Eine allgemeine Vorraussetzung ist für die Komponente, das ein und die gleiche Datenbankstruktur der Tabelle im angeschlossenen DataSet schon existiert. Und das hat nichts mit NET zu tun. Also wichtig ist, dass die Komponente nur eine vorhanden DB-Struktur mit Daten füllt. Sie legt keine Struktur im DataSet an.

Das hat aber nichts mit dem eigentlichen Problem zu tun, dass ich mit dem erzeugten XML-File auf dem Handheld, mit einer in C# für das Compact Framework zu .NET geschriebenen Anwendung schlicht nichts anfangen kann, da das Dataset (die Klasse im .NET!) dieses File nicht versteht. Zurück in Delphi ist nicht das Problem mit dieser Kompo ;)

Zitat:

Zitat von mschaefer

Das andere ist wohl eine WLAN-Thematik und fordert einen neuen Thread.

Der ja bereits existiert, aber bis zur Klärung ob SQL Mobile eine Lösung wäre auf Eis liegt :)

Zitat:

Zitat von mschaefer

Versuche mal die Paradoxtabelle mit einer Netanwendung zu laden. Im zweiten Schritt dann die XML-Komponente an diese Netwanwendung anzuflanschen.

Wie soll ich C# diese Kompo denn servieren? Auf Portieren habe ich ehrlich gesagt keine Lust ;) Ich habe kein D2005! Ich arbeite mit dem VisualStudio 2003, da D2005 mit dem CF nichts anfangen kann.

[mschaefer]

Hm, auf keine Lust habe ich keine Antwort.

Da hat sich das dann mit XML, den letztlich liegt die Logik ja jeweils nur in der Speichern/Laden Routine und C# ist soweit von Delphi nicht entfernt. Was das Überspielen angeht, kannst Du auf dem PC einen Webserverlaufen laufen lassen und eine Webseite mit Upload und Download anbieten. Vielleicht kann der Pocket -PC auch FTP. Das hängt jetzt daran was C# für Komponenten bereitstellt. In Delphi gibt es Indy zum Übertragen und das läuft bestens. Stellt sich wieder die Frage was C# bietet. Visual-Studio kommt mir sobald nicht auf die Platte, damit bin ich raus...


Grüße // Martin

[dizzy]

Zitat:

Zitat von mschaefer

Da hat sich das dann mit XML, den letztlich liegt die Logik ja jeweils nur in der Speichern/Laden Routine und C# ist soweit von Delphi nicht entfernt.

Das mag sein, aber die gesamte Komponente nach C# zu übersetzen (das schließt ja nicht nur "begin" durch "{" ersetzen ein, sondern eine komplette Anpassung an Basisklassen und div. andere Teile die genutzt werden, das komplette Umbiegen an allen Stellen die "unsafe" sind und und und... Das erfordert weit mehr Arbeit und vor allem Zeit (ich denke bei der Größe und Komplexität der Kompo sprechen wir von einigen Tagen (ich bin allein, und das ist zudem mein aller aller erstes Mal mit C#!)), als ich dafür aufbringen kann.

Zitat:

Zitat von mschaefer

Was das Überspielen angeht, kannst Du auf dem PC einen Webserverlaufen laufen lassen und eine Webseite mit Upload und Download anbieten. Vielleicht kann der Pocket -PC auch FTP. Das hängt jetzt daran was C# für Komponenten bereitstellt. In Delphi gibt es Indy zum Übertragen und das läuft bestens. Stellt sich wieder die Frage was C# bietet.

Eine Website auf dem PC wäre eine gute Idee, mit dem unschönen Nachteil, dass eigentlich nicht das Handheld abholen, sondern der PC draufpacken sollte. Aber das wäre im absoluten Zweifelsfall noch verschmerzbar :).
Das mit der FTP-Übertragung ist auch eine Überlegung wert! Eigentlich müsste mir das CF da auch Server und Clients für bieten (hoffe ich einfach mal). Das kommt in die nähere Auswahl ;)

Zitat:

Zitat von mschaefer

Visual-Studio kommt mir sobald nicht auf die Platte, damit bin ich raus...

Ich verstehe zwar nicht warum du das VS verschmähst :), aber ich danke dir trotzem herzlich für deine Vorschläge! Das mit FTP wäre u.U. echt noch eine gute Alternative.

Gruss,
Fabian

[Robert_G]

Darf ich trotzdem nochmal den WebService in die Runde werfen? :roll:
Billiger gates doch nun wirklich nicht...
DataAdapter auf den Service designer... Select Statement eingeben, generate typed data set,...
Nun noch sowas:

Code:

[WebMethod]
DeineDataSetKlasse GetData()
{
  DeineDataSetKlasse ds = new DeineDataSetKlasse();
  dataAdapter.Fill(ds);
  return ds;
}

Im CF Projekt fügst du eine Webreferenz hinzu, dadurch werden auch dort die nötigen Klassen und ein Proxy für den Service angelegt.
nun im CF Project:

Code:

DeinProxy service = new DeinProxy();
DeineDataSetKlasse ds = service.GetData();
ds.DeineTabelle.WriteXml('DateiName.xml');

Ist nicht schön... aber allemale schöner als irgendeine komische Komponete, die irgendein komisches XML File nach irgendeinem komischen Format erzeugt, dass du nun auch noch martialisch rüberprügeln musst...