Re: DataSet vor Update säubern
- From: "Ralf Hermanns" <RalfH@xxxxxxx>
- Date: Tue, 8 Nov 2005 10:23:12 +0100
"Peter Fleischer" schrieb im Newsbeitrag...
> Ralf,
> deine Schilderung ist aber schwer zu verstehen:-9
>
>> Ich lese eine flache (kein XML) Textdatei in ein DataSet, und
>> normalisiere zurück auf 2 Tabellen (Parent-Child Relation), um dieses
>> dann irgendwann in eine DB zu schreiben.
>
> Was ist der Unterschied zwischen einer flachen und einer tiefen Textdatei?
Das kleine Wörtchen "flach" wahrscheinlich ist der entscheidende Punkt zum
Verständnis meiner etwas verkorksten Frage. Mit "flach" meinte ich, dass die
Daten angeordnet sind wie nach einem Join, also jede Zeile enhält die
Parent-Info in den ersten (linken) Spalten, und die dazugehörige Child-Info
in den letzten (rechten) Spalten.
Ungefähr so, z.b.:
Parent-Teil Child-Teil
id name Uhrzeit Ort
1 Müller 15:00 Aachen
1 Müller 16:00 Köln
1 Müller 17:00 München
2 Meier 14:00 Augsburg
2 Meier 18:00 Nürnberg
1 Müller 19:00 Stuttgart
Im Gegensatz dazu wäre eine "tiefe" Datei etwas in XML Form, so in der Art
<Parent id=1 name=Müller>
<Uhrzeit=15:00 Ort=Aachen>
<Uhrzeit=16:00 Ort=Köln>
<Uhrzeit=17:00 Ort=München>
<Uhrzeit=19:00 Ort=Stuttgart>
</parent>
>> Es gibt Zeilen, in denen schon mal ein Child ungültig ist, diese
>> möchte ich nicht in die Datenbank übernehmen (den gesamten Parent mit
>> allen seinen auch vielleicht später in der Datei kommenden Childs
>> nicht!)
>
> Bringt denn ein später kommendes Cild keinen Parent mit?
Das ist der springende Punkt: Ich kenne die Parents (hier: Müller Meier)
selber nicht vorher nicht.
Jedesmal wenn ein vorher noch nie gesehener Name (geht natürlich über id)
kommt, wird dafür im Dataset ein neuer Parent angelegt, und der Childteil
dieser Zeile in der Child-Tabelle. Jede weitere spätere Zeile (dieses
Parents) wird dann als Child nur noch diesem Parent zugeordnet, auch wenn
zwischendurch andere Zeilen waren. Sozusagen ent-joint, oder eben wieder
zurück normalisiert.
Das müsste aber eigentlich ein ganz üblicher Vorgang sein. Bei XML braucht
man das nicht, klar, da "sieht" man ja quasi was zusammengehört, aber bei
"flachen" Dateien geht das nicht anders. Schreckliche Beschreibung, aber wie
sonst nennen?
> Wenn ich es richtig verstanden habe, dann wird jede eingelesene Zeile der
> Textdatei in einen Eintrag für die Parent-Tabelle und einen Eintrag für
> die Child-Tabelle zerlegt.
Nein, eben nicht. Siehe oben. Nur für neue Parents gibts einen neuen
Parenteintrag!
> Jeder Parent bekommt bei der Neuanlage einen Status "gültig". Wenn jetzt
> die Prüfung "ungültig" ergibt, wird der Status im Parent entsprechend
> gesetzt. Wenn in einer neuen eingelesenen Zeile ein bereits vorhandener
> Parent identifiziert wird, wird der Status des Parent nicht geändert.
> Falls dann die weiteren Prüfungen wieder "ungültig" ergeben, wird der
> Status im Parent auf "ungültig" gesetzt, egal, was war. Nach dem Einlesen
> aller Daten werden alle ungültigen Parents mit deren Childs gelöscht (z.B.
> Filter auf Status="ungültig"). Danach können dann die Daten in die DB
> eingetragen werden.
Ja, genau das ist die Frage, dieser Status den du beschreibst, darum geht
es!
Was ich wissen will ist, ob ich als Status irgendein Property des Dataset
(eher der jeweiligen Datarow) nehmen kann, so dass _im Speicher_ die Zeile
noch existiert um Childs anhängen zu können die später als die ungültig
machende kamen, beim .UPDATE diese Zeilen (mit ihren Anhängen) aber nicht
geschrieben werden. Automatisch sozusagen.
Jede Datarow um ein Feld "gültig" zu verlängern, und vor Schreiben selber
Filtern ginge. Ebenso die ParentIDs, die raus müssen in einer Arraylist
notieren, und vor Schreiben rauswerfen (das mache ich zur Zeit, klappt gut,
bleibt so - aber nicht schön).
Wenn ich mal viel Zeit habe, mache ich ein paar Versuche in folgende
Richtungen:
Meine Idee war es, einen Status in der Parent-Datarow so zu ändern, das die
schlechten Zeilen, Parent _und_ Childs, von .UPDATE automatisch ignoriert
werden, ohne Listen mitzuführen und Säuberungsprozeduren zu brauchen.
Plan 1) Rowstate=original würde ihn dahingehend täuschen, das die Zeile
schon vorher da war und nicht geschrieben werden muss - geht aber nicht auf
die Childs über (oder?)
Plan 2) Rowstate=deleted müsste ihn dazu veranlassen, SQL Delete-Statements
zu erzeugen. Der DA hat kein Delete-Command - was passiert dann? Geht aber
auch nicht auf Childs über.
Plan 3) Parentrow.delete "detacht" die Zeile interessanterweise, ich hätte
gedacht das wäre mit 2) identisch. Das sollte sich auf die Childs
übertragen, aber warum detached? Es gibt doch rowstate deleted... Das klappt
übrigens gut, hat aber den Nachteil das es am Schluss in einer eigenen
Säuberungsprozedur sein muss. (Denn sonst würden spätere Childs diesen
Parent erneut erzeugen, oben beschrieben!!)
Plan 4) Ich bin sicher, auch Datarow.remove schon gesehen zu haben.
Vielleicht kann das was?
.
- Follow-Ups:
- Re: DataSet vor Update säubern
- From: Peter Fleischer
- Re: DataSet vor Update säubern
- References:
- DataSet vor Update säubern
- From: Ralf Hermanns
- Re: DataSet vor Update säubern
- From: Peter Fleischer
- DataSet vor Update säubern
- Prev by Date: Re: Probleme mit dem ForeingKeyConstraint
- Next by Date: Re: SQL Server Management Studio Express
- Previous by thread: Re: DataSet vor Update säubern
- Next by thread: Re: DataSet vor Update säubern
- Index(es):
Relevant Pages
|
