Dynamische Tabelle
verwendetes Datenbanksystem: <SQL 2005>
ich will mir ein Programm mit C# schreiben, der beliebiege web services konsumiert. Diese Web Services liefern alle unterschidliche Tabellen. Wie kann ich eine Tabelle auf dem Datenbank dynamisch erstellen und die von Web Services erhalten Table füllen?
danke
ich weiss wie mann tabelle erstellt. Ich weiss aber nicht wie man eine Tabelle erstellt jenach erhatene Tabelle mit unterschidlichen Spalten von Web Services.
Ich glaube, er möchte Daten beliebiger Webservices in jeweils extra Tabellen speichern.
Nunja - nach dem Konsumieren der WSDL hast du ja deine Objektbeschreibungen. Und aus denen kannst du per reflection die Properties und ihre Typen entnehmen. Die übergibst du an eine Stored Procedure, das im wesentlichen das Create Table ausführt. Fertig.
LaTino
"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)
danke LaTino,
gibt es irgendwie keine Möglichkeit ohne Reflection dies zu realisieren?
DataTAble dt = service.GetTable();
.
.
.
connection.CrateTable(dt) oder comand.CreateTable(dt) oder soo?
das kann ich machen aber es muss irgendwie leichter gehen.
ich habe ein DataSet eine Tabelle und die habe alle Informationen.
Kurze Antwort:
Meines Wissens nach nicht.
Lange Antwort:
Vermutlich wird das Entity Framework "bald" das Erstellen von Datenbanken inkl. Tabellen und Prozeduren aus einer Modelldefinition heraus beherrschen. Wenn es soweit ist, muss man nur noch aus einer WSDL ein Entitätenmodell dynamisch erzeugen, und das dann speichern.
Klingt nach einer interessanten Aufgabe.
Bis dahin würde ich mich mit reflection begnügen, oder - für faule - eine Tabelle für alle Webservice-Antworten benutzen, in der die Antworten in einem XML-Feld gespeichert werden.
Ersteres klingt in meinen Ohren schöner.
Gruß,
LaTino
EDIT: Wenn du alles schon in einem Dataset hast, was genau hindert dich daran, die Namen der Spalten aus dem DataSet abzufragen und in eine Create-Table-Anweisung einzubinden?
"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)
Hallo vollmond,
aber es muss irgendwie leichter gehen.
jo mein Gott 😉
-> Also .NET Bordmittel, das geht net. Selbst Ado.NET geht immer von einer anderen Richtung aus. Es liest die Tabellenstruktur der DB und übersetzt diese in das DataSet/DataTable.
Wenn Du also den umgekehrten Weg haben willst, dann bleibt Dir nur die Möglichkeit, das händisch zu lösen. Da würde ich mir eine eigene Klasse schreiben, die Dir automatisch aus einem Dataset die DataTables ausliest, dort dann die Spalten(typen) durchgeht und aus diesen Informationen dann einen "Create Table" SQL Befehl generiert.
Das macht man dann einmal, und mit Hilfe dieser Klasse kann man dann alle DataSets/DataTables übersetzen lassen.
Eine andere (leichtere) Möglichkeit sehe ich nicht. Schneller geht es eventuell nur, wenn Du im Netz schon eine fertige Implementierung findest. z.B. Codeproject oder dergleichen.
Grüße
Norman-Timo
P.S.: Falls Du Dir selbst die Mühe machst, dann kannst Du das Ergebnis ggf. als Snippet Komponente hier im Forum veröffentlichen (Falls Du darfst/willst).
A: “Wie ist denn das Wetter bei euch?”
B: “Caps Lock.”
A: “Hä?”
B: “Na ja, Shift ohne Ende!”
DataTAble dt = service.GetTable();
Das würd mich aber wundern, wenn das ginge... Datatables sind nicht serialisierbar, und können somit nicht von Webservices zurückgegeben werden.
Aber zu deinem Problem: Ich würds auch so lösen wie norman_timo. Mit .NET Bordmitteln kann das nicht gehen. Datasets sind entkoppelt von der physischen Datenhalten, es ist ihnen also egal ob sie bspw. aus einem XML oder einer SQL Datenbank stammen. Wenn jetzt ein Dataset plötzlich ein Tabelle generieren würde, wär das ein Regelbruch.
Datatables sind nicht serialisierbar
seit wann???
Datatables können jedenfalls nicht von Webservices zurückgegeben werden:
siehe auch hier
Hallo Jelly,
Datatables können jedenfalls nicht von Webservices zurückgegeben werden
Das ist allerdings wiederum richtig, dennoch können DataSets serialisiert werden. Das sind 2 paar Schuhe.
Warum das bei WebServices nicht geht, liegt vereinfacht gesprochen daran, weil ein gültiges WSDL Dokument dem WebService zugrunde liegen muss. Auch alleine wg. der Plattformunabhängigkeit, so dass auch ein Linux-Client mittels Java einen C# WebService aufrufen kann. -> Ein DataSet ist halt nur innerhalb von .Net gültig 😉
Grüße
Norman-Timo
A: “Wie ist denn das Wetter bei euch?”
B: “Caps Lock.”
A: “Hä?”
B: “Na ja, Shift ohne Ende!”
Hm? Die Erklärung verstehe ich beim besten Willen nicht. Warum sollte es einem Java-Client nicht moeglich sein, das serialisierte DataSet zu konsumieren und auszuwerten? Klar wird er wohl kaum das .NET-Objekt erstellen können, aber mit den Daten kann er doch hantieren.
Ich probier's heut abend mal aus. Mir will nicht in den Kopf, wieso sonst jemand bereits vor 6 Jahren folgendes Tutorial hätte schreiben sollen:
Leicht verwundert,
LaTino
"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)
Warum das bei WebServices nicht geht, liegt vereinfacht gesprochen daran, weil ein gültiges WSDL Dokument dem WebService zugrunde liegen muss. Auch alleine wg. der Plattformunabhängigkeit, so dass auch ein Linux-Client mittels Java einen C# WebService aufrufen kann. -> Ein DataSet ist halt nur innerhalb von .Net gültig 😉
Wusst ichs doch... Irgendwas war da. Danke für die tiefergehende Erklärung.
Eins versteh ich in deiner Aussage nicht. Du sprichst von Plattformunabhängigkeit. Aber weil das Dataset ja nur von .NET Clients entgegengenommen werden kann, ist die Plattformunabhängigkeit ja flöten. Und wenn DataTables übergeben werden könnten, wär sie halt auch flöten.
So, hab's ausprobiert.
Es ist nicht richtig, dass DataSets nicht von einem Webservice übertragen werden können.
Richtig ist vielmehr, dass - wie in dem Artikel, den Jelly verlinkt hat, beschrieben ist - einzelne DataTables unter Umständen nicht übertragen werden können. Befinden sie sich in einem DataSet, das übertragen wird, ist das kein Problem.
Die Schwierigkeit liegt offensichtlich nicht darin:
Warum das bei WebServices nicht geht, liegt vereinfacht gesprochen daran, weil ein gültiges WSDL Dokument dem WebService zugrunde liegen muss. Auch alleine wg. der Plattformunabhängigkeit, so dass auch ein Linux-Client mittels Java einen C# WebService aufrufen kann. -> Ein DataSet ist halt nur innerhalb von .Net gültig 😉
Weil diese Begründung bedeuten würde, dass KEIN C#-Objekt mittels WebService übertragen werden kann. Nein, ein .NET-String ist eben kein Java-String, kein Perl-String, kein PHP-String auch auch sonst kein String irgendeiner Sprache, die mit Webservices kommunizieren kann.
Ich gehe von einer internen .NET-Problematik aus, die verhindert, dass ein DataTable ohne zugehöriges DataSet in einen entsprechenden SOAP-Umschlag serialisiert werden kann.
Gruß,
LaTino
"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)
Hallo LaTino,
danke für Deinen Test, sohab auch ich etwas dazu gelernt, so oft verwende ich WebServices dann auch nicht.
Was ebenfalls interessant sein sollte:
WebService rückgabe Daten mit Funktion
Ich war der Überzeugung, dass DataSets zu den komplexen Objekttypen gehören, die nicht über WebServices übertragen werden könnten.
Grüße
Norman-Timo
A: “Wie ist denn das Wetter bei euch?”
B: “Caps Lock.”
A: “Hä?”
B: “Na ja, Shift ohne Ende!”
Yup, den Thread hätte ich mal 6-8 Monate früher lesen sollen, da hatten wir dasselbe Problem. Wäre aber auch zu schön, hätte man eine Übertragung, die komplette Objekte übertragen kann. Ich stelle mir grad folgendes vor:
RubyService myRubyService = new RubyService();
String result = myRubyService.GetRubyString("hello, world");
Console.Write(result.chop().capitalize().reverse());
Bei genauerer Betrachtung wäre das nicht schön, sondern gruselig.
😁
LaTino
"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)
So, hab's ausprobiert.
Es ist nicht richtig, dass DataSets nicht von einem Webservice übertragen werden können.
Richtig ist vielmehr, dass - wie in dem Artikel, den Jelly verlinkt hat, beschrieben ist - einzelne DataTables unter Umständen nicht übertragen werden können. Befinden sie sich in einem DataSet, das übertragen wird, ist das kein Problem.
Die Schwierigkeit liegt offensichtlich nicht darin:
Warum das bei WebServices nicht geht, liegt vereinfacht gesprochen daran, weil ein gültiges WSDL Dokument dem WebService zugrunde liegen muss. Auch alleine wg. der Plattformunabhängigkeit, so dass auch ein Linux-Client mittels Java einen C# WebService aufrufen kann. -> Ein DataSet ist halt nur innerhalb von .Net gültig 😉
Weil diese Begründung bedeuten würde, dass KEIN C#-Objekt mittels WebService übertragen werden kann. Nein, ein .NET-String ist eben kein Java-String, kein Perl-String, kein PHP-String auch auch sonst kein String irgendeiner Sprache, die mit Webservices kommunizieren kann.Ich gehe von einer internen .NET-Problematik aus, die verhindert, dass ein DataTable ohne zugehöriges DataSet in einen entsprechenden SOAP-Umschlag serialisiert werden kann.
Gruß,
LaTino
Das Problem ist, daß eine DataTable oder auch ein untypisiertes DataSet keine Grundlage für den Webservice bieten, ein WSDL-Dokument (das ja den verbindlichen Vertrag zur Nutzung des Dienstes darstellt) zu erzeugen. Die DataTable kann sich je nach Programmablauf ändern, beispielsweise indem ein Programmteil Spalten hinzufügt oder entfernt. Die Struktur des Antwortdokuments muss bereits vor dem Programmablauf vollständig und bis in die letzte Ebene bekannt sein, das ist bei untypisierten DataSets nicht gegeben.
warum versendet ihr dann nciht einfach ein xml-serialisiertes objekt? das kann von jeder anderen sprache geparst werden und in eine sprachenspezifische struktur gewandelt werden.
Recht hast du.
Wäre schnell geschrieben, weniger fehleranfällig, unabhängig von (zB) der Reihenfolge der Abfrageparameter im SQL. Ergebnisse von SQL-Abfragen in DataSets zu packen und dann die Werte im DataSet weiter zu bearbeiten, ist eine grauenhafte Methode.
EDM (oder meinetwegen Linq-To-Sql-Model) entwerfen, serialisierbar markieren, fertig.
Gruß,
LaTino
"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)