SQL->XML->SQL

[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 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!

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 von Robert_G:

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

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

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 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 Ich habe etwa 20% von dem verstanden was du da geschrieben hast . 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
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 .

[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 .

[mschaefer]

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

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 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 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 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