"dynamisches INSERT" geht das? oder wie kann ich das sonst noch machen?

Hallo Leute.

Hab schon die Suchfunktion vollkommen ausgereizt...aber nix zu meinem Problem gefunden.

Und zwar geht es darum, dass ich Messdaten aus ner XML-Datei auslese. Soweit so gut.
Die Attribute können allerdings auch mehr werden. d.h. Brauch ich eine Dynamische Tabelle, die nach dem auslesen des XML-Files checkt, ob sich die Anzahl der Spalten verändert hat. und wenn ja eine Neue Tabelle mit den neuen Spalten anlegt.
Das dürfte ich allerdings hinbekommen.
Nun ist aber das Problem, dass ich ja das Dataset des XML Files wieder auf die DB spielen muss. Da ich ja aber nicht weiss, wie groß meine Tabelle in den einzelnen Fällen ist, müsste ich quasi ein "dynamisches INSERT" erzeugen, mit dem ich die Daten in die Tabelle fülle.
Soweit ich das mitbekommen habe, kann ich ja nur über ein INSERT an die DB ran.
Schön wärs, wenn ich das Dataset einfach nur auf die DB übertragen könnte 🙂
Also ich hoffe ich konnte euch mein Anliegen einigermaßen gut rüberbringen.
Hoffe Ihr könnt mir diesbezüglich weiterhelfen

Gruß Micha

Hallo BenFire,

Schritt 1: XML-Datei auslesen und alle Spalten holen
Schritt 2: SqlCommand (z. B. xCommand) mit SqlParametern (xCommand.Parameters) erstellen. JA 'SqlParametern' oder 'Parameter'. Dürfte glaube ich beides gehen.
Schritt 3: xCommand.Insert durchführen.

Die Attribute können allerdings auch mehr werden. ... Brauch ich eine Dynamische Tabelle, die nach dem auslesen des XML-Files checkt, ob sich die Anzahl der Spalten verändert hat.

Wenn du meinst, ob du die Tabelle in der Datenbank dynamisch anpassen kannst: Ja, jedes halbwegs vernünftige RDBMS kennt die DDL-Syntax "ALTER TABLE". Alternativ kannst du auch neue Tabellen anlegen, die diese zusätzlichen Daten aufnehmen. (Nach dem Sinn frage ich besser nicht, denn damit zwingst du, entsprechende Dynamik vorausgesetzt, jeden SQL Server in die Knie.)
Besser wäre es hier, du wüsstest, wieviele Felder du maximal haben musst und würdest die Tabelle(n) statisch vordefinieren. Selbst wenn die Antwort lautet "Es ist unbestimmt, wieviele Felder meine Datensätze haben.", hast du damit schon eine klare Aussage getroffen, für die es optimale DB-Design-Patterns gibt. ... Aber das würde jetzt wohl zu weit führen, fürchte ich...

Wenn du meinst, ob du ein Statement dynamisch erzeugen kannst: Ja, auch das ist möglich. Vergewissere dich zunächst, dass die ausgelassenen Felder in der Datenbank NULL-Werte erlauben (oder sichere sie durch defaults ab).

the rough way
Anschließend erzeugst du ein Statement, das etwa so aussehen könnte

-- T-SQL Statement
-- Insert mit wahlfreien Attributwerten

INSERT INTO [Tabellenname]
(Wert1, Wert2, Wert3, ...) -- Hier alle Felder der Tabelle aufnehmen, für die "not NULL" definiert ist, oder denen Werte zugewiesen werden (müssen)
VALUES 
(oWert1.Value, oWert2.Value, oWert3.Value, ...) --- Hier alle Daten für einen Satz aufnehmen. Dabei gilt, dass Wert1 den oWert1.Value aufnimmt. Nicht vorhandene Werte mit NULL (oder Default-Werten) belegen.

the smart way
Wenn du mit SQL-Syntax nicht vertraut bist, geht das übrigens auch mit dem CommandBuilder (SqlCommandBuilder, OdbcCommandBuilder). Die machen das automatisch (zur Laufzeit und deshalb dynamisch an die eingelesenen Daten angepasst) für dich. Daher funktioniert der folgende Weg durchaus auch:

Schön wärs, wenn ich das Dataset einfach nur auf die DB übertragen könnte. ... "dynamisches INSERT" ...

Geht auch.

1. XML-Daten in das Dataset einlesen.
2. Datatables um die "fehlenden" Spalten erweitern. (Optional, wenn die Datenbank/Tabelle es zulässt.)
3. DataAdapter erzeugen. (Connection, etc.)
4. Insert-Command am DA etablieren (vordefiniert oder dynamisch generiert)
5. DataSet tabellenweise oder en bloc über DataAdapter "updaten"

Jeder Weg hat Vor- und Nachteile: Der direkte Weg ist effektiver, performanter, sowie leichter zu skalieren und warten. Der smarte Weg ist einfacher und schneller geschrieben, dafür aber auch um Längen weniger performant. Welchen du wählen solltest, hängt von Anforderungen ab, die du hier nicht (ausreichend) dargestellt hast.

Na das sieht doch schonmal ganz fein aus.
Sorry das ich das vergessen hab. Meine DB ist SQL....das ALTER TABLE hatte ich schon ganz vergessen, dass es sowas gibt....das macht die sache erheblich leichter 🙂

Das Insert muss ja dann halt von der Anzahl der spalten dynamisch sein.
Sprich wenn ein Atribut mehr dazukommt, so muss der Insertbefehl auch ein Attribut mehr einfügen.
Denn wie gesagt, die Anzahl ist abhängig von der Attributanzahl in der XML datei.
immer wenn dann z.b. eine neue Spalte dort auftaucht, muss sich die Tabelle vergrößern und der INSERTbefehl auch um eine Stelle verlängern.
Dann ist halt fraglich, ob das so funktioniert?

INSERT INTO [Tabellenname]
(Wert1, Wert2, Wert n, ... + neuer Wert )

Hi,

Warum sollte es nicht möglich sein?
Du fragst alle Tabellenspalten ab, fehlt deine Spalte/n, dann lässt du sie erzeugen. Je nach Spaltenstruktur kann es auch reichen, die Anzahl der Spalten zu zählen und zu prüfen, ob diese ausreichen.
Jetzt kannst du die Daten eintragen lassen. Dazu musst du einfach dein String zusammenbauen lassen in einer Schleife.

Gruß Thomas

Jo sowas hatt´ ich mir auch schon gedacht.
Na ich werds mal probieren
Danke für eure Hilfe

Die Attribute können allerdings auch mehr werden. ... Brauch ich eine Dynamische Tabelle, die nach dem auslesen des XML-Files checkt, ob sich die Anzahl der Spalten verändert hat.
Wenn du meinst, ob du die Tabelle in der Datenbank dynamisch anpassen kannst: Ja, jedes halbwegs vernünftige RDBMS kennt die DDL-Syntax "ALTER TABLE". Alternativ kannst du auch neue Tabellen anlegen, die diese zusätzlichen Daten aufnehmen. (Nach dem Sinn frage ich besser nicht, denn damit zwingst du, entsprechende Dynamik vorausgesetzt, jeden SQL Server in die Knie.)
Besser wäre es hier, du wüsstest, wieviele Felder du maximal haben musst und würdest die Tabelle(n) statisch vordefinieren. Selbst wenn die Antwort lautet "Es ist unbestimmt, wieviele Felder meine Datensätze haben.", hast du damit schon eine klare Aussage getroffen, für die es optimale DB-Design-Patterns gibt. ... Aber das würde jetzt wohl zu weit führen, fürchte ich...

Wenn du meinst, ob du ein Statement dynamisch erzeugen kannst: Ja, auch das ist möglich. Vergewissere dich zunächst, dass die ausgelassenen Felder in der Datenbank NULL-Werte erlauben (oder sichere sie durch defaults ab).

the rough way
Anschließend erzeugst du ein Statement, das etwa so aussehen könnte

  
  
-- T-SQL Statement  
-- Insert mit wahlfreien Attributwerten  
  
INSERT INTO [Tabellenname]  
(Wert1, Wert2, Wert3, ...) -- Hier alle Felder der Tabelle aufnehmen, für die "not NULL" definiert ist, oder denen Werte zugewiesen werden (müssen)  
VALUES   
(oWert1.Value, oWert2.Value, oWert3.Value, ...) --- Hier alle Daten für einen Satz aufnehmen. Dabei gilt, dass Wert1 den oWert1.Value aufnimmt. Nicht vorhandene Werte mit NULL (oder Default-Werten) belegen.  

the smart way
Wenn du mit SQL-Syntax nicht vertraut bist, geht das übrigens auch mit dem CommandBuilder (SqlCommandBuilder, OdbcCommandBuilder). Die machen das automatisch (zur Laufzeit und deshalb dynamisch an die eingelesenen Daten angepasst) für dich. Daher funktioniert der folgende Weg durchaus auch:

Schön wärs, wenn ich das Dataset einfach nur auf die DB übertragen könnte. ... "dynamisches INSERT" ...
Geht auch.

1. XML-Daten in das Dataset einlesen.
2. Datatables um die "fehlenden" Spalten erweitern. (Optional, wenn die Datenbank/Tabelle es zulässt.)
3. DataAdapter erzeugen. (Connection, etc.)
4. Insert-Command am DA etablieren (vordefiniert oder dynamisch generiert)
5. DataSet tabellenweise oder en bloc über DataAdapter "updaten"

Jeder Weg hat Vor- und Nachteile: Der direkte Weg ist effektiver, performanter, sowie leichter zu skalieren und warten. Der smarte Weg ist einfacher und schneller geschrieben, dafür aber auch um Längen weniger performant. Welchen du wählen solltest, hängt von Anforderungen ab, die du hier nicht (ausreichend) dargestellt hast.

Hallo, ichhabe gerade das selbe Problem. Ich lese eine Tabelle mit Maschinen ein und stelle die jeweils in drei Panels da (jedes Panel für eine Schicht, Schichtarbeitsmodell).
Das pasiert also dynamisch. Nun kann es sein das morgen drei neue Maschinen gekauft werden. Ich trage diese Maschinen auch in die Liste ein. DIe Maschinen werden nun beim PRogrammstart automatisch in den Panels aufgelistet. Wenn ich nun die Maschinen für die Wochenübesicht einplane, habe ich das Problem das die drei neuen Maschinen nicht als Spalten in der Kalendertabelle, wo alle Maschinen in der Tagesübersicht aufgelistet sind nicht vorhanden sind. Ich müßte diese nun auch dynamisch der SQL-Tabelle zufügen. Im Dataset habe ich das schon gemacht, funktioniert dort auch.
Jetzt muß ich die neuen Spalten nur noch per Transact-SQL einfügen? Wie binde ich das in meinen Code ein? Habe das gerade mal versucht aber funzt nicht ??
(Verwende typ. DataSet).

Auch wenn's vielleicht schon zu spät ist, erheb ich hier trotzdem mal den (virtuellen) mahnenden Zeigefinger (bzw. den Daumen nach unten, weil's dafür so ein schönes Smiley gibt): 🙄

a) Dynamisch (also aufgrund der Inhaltsdaten) Anpassungen an der Datenbankstruktur vorzunehmen (bzw. vornehmen zu müssen) zeugt IMHO von unsauberem Design der Struktur
und ausserdem geht es b) auch völlig ohne dynamisch die Tabellen zu verändern (Stichwort: Normalisierung, Referenzen, etc.)

Aufgrund der Tatsache, dass vermutlich schon in die (aus meiner Sicht falsche) Richtung entwickelt wurde (und weil ich faul bin :evil: ), spar ich mir jetzt mal "Lösungsansätze und weitere Details" - kann aber bei interesse gern was liefern 😁

Bart Simpson

P.S. Ich bin mir durchaus bewusst, dass es legitime Gründe geben kann, dynamisch die DB-Strukturen zu ändern - der konkrete Anwendungsfall (so ich ihn denn richtig verstanden habe) scheint mir aber keiner dafür zu sein.

Hallo Bart, dann geb mir noch einen Tipp bevor ich falsch ansetze.

Hi,

also hier bin ich bei der Lösung auch faul.
Ich kann dir die Lösung nicht schreiben, da
man da einfach dein Wissen für benötigt.
Wie Mr. Bart Simpson schreibt Normalisiereung! Er hat recht.

Das ist eine Fleißarbeit für dich.

In deinem Falle gibt es mehrere gleich komplizierte Lösungen.
Es fehlt zum Beispiel der Hintergrund wieviele Daten gespeichert werden.
Eben wegen der Geschwindigkeit. Soll es 1 - N Attribute ermöglichen
oder ist es eher Normal das es max 20 Atrribute sind und ab und zu mal auf 25 anwächst?

Es fehlt hier z.b. welche SQL Datenbank Software du verwendest.
Bei einer MSSQL bist du auf 8000 Zeichen oder 4000 Unicodezeichen pro Row beschränkt.
Also würde es auf die dauer nicht gut gehen wenn du 8000/u4000 knacken würdest.
Wäre das der fall, dann würde dein Import vor die Wand laufen.
Also nachlesen ob es von der Datenbank Software beschränkungen gibt.

Wenn du max 1000 Datensätze in der Datei hast, dies Dynamisch speicher in der Datenbank.
Tabellen: Satz - SatzAttribute - SatzWerte
Ein Satz wird erzeugt beim Import. Alle Attribute werden dann gespeichert.
In Satz Werte ist dann [SatzID],[SatzAttributId], [Wert]
Dies kann man dann einfach per Dynamischer Abfrage/SQL selber zusammenbauen und darstellen.

Wie gesagt du must dir halt dazu noch mehr gedanken machen.

MfG
Björn

Ein (sehr einfacher) Ansatz ist z.B. schon mal, Deine Spalten von den eigentlichen Inhalten zu trennen - z.B. ungefähr so wie im angehängten Schema.gif. (Man beachte: Ich hab hier nur ca. 5 Minuten Zeit investiert - es geht definitv besser...)

Dann kannst Du (im Prinzip) beliebig viele Spalten in die (hier "Bezeichner" genannte) Referenztabelle eintragen und die eigentlichen Daten (in der "Werte"-Tabelle) nur noch darauf verweisen lassen.
Damit ist es z.B. sehr leicht möglich (man beachte die Anführungszeichen!) "über die Spalten zu aggregieren" (z.B. mit SUM oder AVG) indem Du nach der BezeichnerId gruppierst.

Bart Simpson

Ein (sehr einfacher) Ansatz ist z.B. schon mal, Deine Spalten von den eigentlichen Inhalten zu trennen - z.B. ungefähr so wie im angehängten Schema.gif. (Man beachte: Ich hab hier nur ca. 5 Minuten Zeit investiert - es geht definitv besser...)

Dann kannst Du (im Prinzip) beliebig viele Spalten in die (hier "Bezeichner" genannte) Referenztabelle eintragen und die eigentlichen Daten (in der "Werte"-Tabelle) nur noch darauf verweisen lassen.
Damit ist es z.B. sehr leicht möglich (man beachte die Anführungszeichen!) "über die Spalten zu aggregieren" (z.B. mit SUM oder AVG) indem Du nach der BezeichnerId gruppierst.

Bart Simpson

Also, ich hab eeine Tabelle, in der jede Maschine einen Datensatz abbildet. In diesem Datensatz sind auch dann Verbrauchswerte usw. für jede Maschine eingetragen. Wenn ein Wochenpaln erstellt wird, wird für jeden Tag und jede Schicht diese aktuelle Maschinenliste geöffnet, jede Maschine mit ihrem Namen aus Datenreihe (Spalte) ausgelesen und dynamisch eine Checkbox mit dem Namen und DataBinding zur CheckBox mit der BindingSource erzeugt. Nun wählt man in einem Kalender den Wochentag aus, markiert alle Maschinen die an dem Tag arbeiten sollen (das Datum wird überprüft, damit kein identischer Tag 2x angelegt werden kann). Dann wird der Datensatz in der Tabelle Maschinenschicht abgelegt. Das sind 60 Maschinen, * 3 Schichten macht dann 180 Spalten. Kommt nun eine Maschine hinzu, dann sind das gleich drei Spalten eil wir drei Schichten pro tag haben. Nun, ic würde die Tabelle dann gern eaus dem COde heraus erweitern und den Spalten die Namen der maschinen mit den SChichthürzel geben.

Hier nachlesen und dein Datenbankkonzept überarbeiten!
Mehr fällt mir nicht ein.

In diesem Datensatz sind auch dann Verbrauchswerte usw. für jede Maschine eingetragen.

Also ich bin mir nicht sicher, ob ich Deine Strukturen da richtig verstehe, aber ich denke, dass Du genau das was ich geschrieben hab nicht umgesetzt hast: Die Trennung der "Werte" (bei Dir wohl Verbrauchsdaten) von den "Referenzen" (bei Dir wohl Maschinen).

Der erste Schritt für eine Normalisierung ist immer, die in Deinem System vorhandenen Entitäten sauber zu identifizieren. Da kann ich Dir aber nicht weiterhelfen, weil ich Deinen Anwendungsfall nicht wirklich verstehe.

Wenn möglich, dann poste doch mal z.B. eine Access-DB die Deine Strukturen (ansatzweise) abbildet - am besten (wenn möglich/zulässig) mit musterhaften Daten. Das macht's allen, die gewillt sind Dir zu helfen deutliche einfacher...

Bart Simpson

Hi, ich habe dich verstanden. Das ist auch korrekt mit der Datenkonsistenz. Aber ich denke in meinem Fall wäre das noch so OK. Es funktioniert nun auch, mit einer gespeicherten Prozedur eine neue Spalte mit Namen einzufügen. Nun habe ich aber noch ein anderes "dickes" Problem. Ich arbeite mit einem typ. DataSet. Das heißt auch, wenn ich in der Tabelle neue Spalten hinzufüge, sind die zwar drin, aber nicht im typ. DataSet. Da muß ich die erst wieder manuell anwählen und das DataSet neu generieren lassen. Gibts da die Möglichkeit, das automatisch generieren zu lassen?

Hi,

auch wenn du Zeitdruck hast,
versuche doch mal das ganze Konzept in Frage zu stellen.
Du baust dir hier gerade immer selber Fallen ein.
Du must immer anpassungen schreiben, die bei einer vernünftigen Datenbankstrucktur und Konzept nicht notwendig sind.
Wenn du ein Diagramm hast schauen wir hier auch gerne drüber und geben dir Tips.

Wenn du ein neues Problem hast dann must du eine neuen Thread anfangen, nicht in diesem
ein neues vorbringen.

MfG
björn

Werde eine erstellen und euch zeigen (heute mittag oder heute abend noch)
Gruß
oehrle

Sorry, am besten die Tabellen rauskoieren und in Excel einfügen, dann passt die Formatierung.

Tabelle Maschinenliste: (hier werden weitere Maschinen manuell eingefügt)

ID MaschName Typ Druckluft Oel KVA Zentralv
1 WZ300x1 Rund 300 450 25 2
2 WZ300x2 Rund 300 450 25 1
3 WZ300x3 Rund 300 450 25 3
4 USx1 Dreh 100 120 10 1
5 MSKx1 Fraes 125 245 15 2

Nun die zweite Tabelle, in der die ganzen aktivierten Maschinen welche dann in der Übersicht angeklickt werden, abgespeichert werden und die VErbrauchswerte addiert und ebenfals in diese Tabelle in die VErbrauchsspalten eingefügt wird.

ID WZ300x1_Fruehschicht WZ300x1_Spaethschicht WZ300x1_Nachtschicht WZ300x2_Fruehschicht WZ300x2_Spaethschicht WZ300x2_Nachtschicht Datum SummeOelvebrauch SummeLuftverbrauch SummeKVA Zentralversorgungen
1 TRUE FALSE FALSE TRUE TRUE TRUE 30.06.2010 1350 900 75 7
2 FALSE TRUE FALSE FALSE FALSE FALSE 01.07.2010 450 300 25 2
3 FALSE FALSE FALSE TRUE FALSE FALSE 02.07.2010 450 300 25 1
4 FALSE FALSE TRUE FALSE FALSE FALSE 03.07.2010
5 FALSE FALSE FALSE FALSE TRUE FALSE 04.07.2010

Nun, so sieht der Aufbau Grundsätzlich aus. Nur habe ich im Moment 60 Maschinen und viel mehr Verbrauchswerte.
In der zweiten Tabelle wird also die Tagesüberischt für alle drei Schichten abgelegt, und die Verbruachswerte sowie die aktiven VErsorgungseinheiten abgelegt und berechnet.

Wird jetzt in der Maschinentabelle eine neue Maschine eingetragen, muß die zweite Tabelle automatisch erweitert werden (Spalten einfügen, was nun auch schon funktioniert). Nun muß ich noch das typ. DataSet automatishc aktualisieren lassen, habe aber noch keine Ahnung wie ich das machen soll.

Hallo, habe gerade noch im Forum danch gesucht. Das wird wohl nicht so funzen, mit dem aktualisieren per Code. Sieht so aus als müßte ich in untyp. DataSet verwenden.

Entschuldige, wenn ich dir das so sage, aber die 2te Tabelle ist Schwachsinn.

Das wiederspricht jedweder Verwendung einer Datenbank.

Die Tabelle Maschinen is okay.

Bei der 2ten Tabelle brauchst du:

ID - Autowert
fk_Maschine
Fruehschicht
Spaetschicht
Nachtschicht
Datum
Dann noch deine ganzen Summen, wobei sich die wahrscheinlich auch einfach berechnen lassen, was aber bei 60 Maschinen in etwa 3 Jahrzehnten relevnt werden könnte.

Wenn du das so verwendest, brauchst du exakt 0 neue Spalten und kannst über fk_maschine einfach deine Werte UNIQUE halten.

Wobei mir das mit den 3 Schichten auch ned gefällt, so kannst du nie deine Verbräuche pro Schicht auswerten. Bist du dir sicher, dass das deine Aufgabenstellung ist?

So kommen wir weiter... 😉

Wenn ich Deine Struktur richtig interpretiere, fehlt's da wie schon gesagt an der Normalisierung. Ich hab's mal eben in Access zusammengeklickt (also bitte nicht an Details rummeckern), aber im Prinzip müsste das Schema wohl so ungefähr wie im angehängten Bild aussehen.

Allerdings versteh ich nicht, was die Spalten "KVA" und "Zentralversogung" bedeuten und hab sie mal als weitere Messgrößen mit eingetragen. Ggf. müsste da also noch geändert werden...

Bart Simpson

KVA sind Kilo Volt Ampere. Man schreibt hier nicht Watt, was mathematisch das selbe wäre, weil Watt = Volt * Ampere, von den Einheiten her, um zwischen Wirk und Scheinleistung unterscheiden zu können. Blindleistung gäbe es dann auch noch, da diese im Normalfall aber nicht verrechnet wird, nimmt er nur die Wirkleistung.

Was Zentralversorgung sein soll ist mir auch ned ganz klar.

Du könntest noch die Messwerte "abtrennen", dann wäre er bei neuen Maschinen, die dann irgendwie anders versorgt werden, als blödes Beispiel mal "Holz" genommen, variabler, sonst will er in der Tabelle wieder dynamisch Spalten einbauen.

Du könntest noch die Messwerte "abtrennen", dann wäre er bei neuen Maschinen, die dann irgendwie anders versorgt werden, als blödes Beispiel mal "Holz" genommen, variabler, sonst will er in der Tabelle wieder dynamisch Spalten einbauen.

Vermutlich... Aber da ich mir nicht wirklich über den Anwendungsfall (und damit die am besten geeigneten Entitäten) im klaren bin, hab ich's mal gelassen.

Auserdem wär's wahrscheinlich sinnvoll, den Typ des Messwerts (z.B. int, float, etc.) auszulagern, und dann dynamisch auszuwerten (Nein, ich meine nicht "dynamisch die Tabelle zu ändern", sondern dynamisch z.B. Tabellenspalten via CASE zu selektieren).
Aber das ist das schon der "Fortgeschrittenen-Modus" 😉 Mir geht's in erster Linie darum, die Normalisierung und v.a. die damit verbundenen Vorteile (bzw. nicht mehr nötigen "Klimmzüge" á la ALTER TABLE) aufzuzeigen - Das sollte IMHO nämlich das kleine Einmaleins der Datenbank-Entwicklung sein.

Bart Simpson