Programmerstellung - wie geht man das Projekt am besten an?

das ist bestimmt nur der verhaspelte Designer. wenn du nicht schon alles mögliche verschlimmbessert hast, müsste die vorgehensweise aus meim letztne post hinhauen

dasis schrott - also ich jdfs. keine Ahnung, wo da jetzt eine doppelte Resource herkommt.

kannste neu machen.

im neuen projekt kannste ja relativ viel vom alten hineinkopieren.

ErfinderDesRades (post#4) schrieb:

vergiß Sql (erstmal).

Sql holt und schreibt Daten in eine externe DB.
Im Dataset hast du die Daten aber intern vorliegen. Also vergiß Sql (erstmal). vergiß Sql (erstmal). vergiß Sql (erstmal).

Das Dataset hat eigene Mechanismen, um die Daten zu verarbeiten, die besser in den Kontext von VB passen, denn Sql passt garnet rein

Also vergiß Sql (erstmal).

Welchen Datensatz möchtest du aus deinem Dataset bearbeiten?

Oder guck dir einfach ein paar meiner Samples aussem DB-Tutorial-Bereich an, dass du einen Eindruck bekommst, was man alles treiben kann,, ohne Sql.

Warum machst du nicht direkt im Dataset die entsprechenden Verknüpfungen der Tabellen?

in "DatasetOnly" auf Movie-Tuts wird das detailliert vorgeführt.

Zum Einrichten eines typisierten Datasets
Schlüsselspalten, sowohl ForeignKey als auch Primkey, müssen denselben Datentypen haben. Int32 ist am günstigsten, weil man dann bereits im Dataset-Designer am Primkey Eindeutigkeit mittels "AutoWert=True" einstellen kann.
Alle Relationen müssen mit Beziehungs- und Fremdschlüssel-einschränkung, und deleterule.cascade, acceptrule.none, updaterule.Cascade eingestellt sein. (im "DatasetOnly"-Tut habich noch updaterule.None eingestellt - egal - .Cascate ist erst beim Speichern in Datenbanken notwendig, also bei "Not-DatasetOnly";))

Zur Benamung im Datenmodell:
wähle kurze Namen, und im Singular.
Aus den Namen werden viele Klassen- und Methoden-namen generiert, die meisten beziehen sich auf einzel-Objekte, sodass die Plural-Flexierung zu einer Fehl-Information führt.
Du möchtest doch nicht solche Sachen coden wie nichtwahr eine Durchgefuerhte_TestsRow läßt erwarten, dass da mehrere Tests drinne sind, aber es ist nur ein Test. oder bei "SuitInhalteRow" ist die Fehlleitung noch schlimmer.

Auch die Spalten: bennene alle Primkeys einfach mit ID. (im "DatasetOnly"-Tut habich noch die Primkeys namensgleich mit den ForeignKeys gemacht, aber günstiger ist, der Prim heißt immer "ID". So sieht man schon an der Benamung, welche Spalte einer DataRelation die übergeordnete ist.
Und die ForeignKeys mit "TableNameID", aber das haste ja schon im großen und ganzen.
Was ich giftig finde, ist von diesem Schema abzuweichen:
SuiteInhalte hat ein ForeignKey auf Durchgefuerhte_Tests, der heißt aber nicht Durchgefuerhte_TestsID, sondern (was ja eiglich sinniger ist) TestID. Da merkst du, wie der bescheuerte Name "Durchgefuerhte_Tests" dich verleitet, unschematisch vorzugehen, wo ein schematisches Vorgehen eine enorme Hilfe wäre. Also Durchgefuerhte_Tests dringend umbenennen in Test.

Das Dataset kennt übrigens keine m:n - Relationen, sondern nur 1:n.
ich notiere diese Relation gerne konkret, und mit Pfeil, also zb die Relation Version->Test
eine m:n - Relation besteht einfach aus zwei 1:n - relationen, mit gemeinsamer n - seite. Anders gesagt: Eine Mittler-Tabelle ist beiden Tabellen untergeordnet.

Bei dir etwa ist Version->Test<-SuitInhalt eine m:n zwischen Version und SuitInhalt.

In deim Modell fehlt also die mittlertabelle zw SuitInhalt und Liste_Einzeltests (der zweit-bescheuertste Name des Datasets).

Eine 1:1 - Relation kennt Dataset auch nicht - was soll das bedeuten, eine 1:1 - Relation?

Also dein Datenmodell ist stimmig, wenn du es mir erklären kannst. Zu verstehen bilde ich mir ein, dasses Tests gibt, und jeder Test kann mehrere Fehler ergeben. Scheinbar gibts Tests in verschiedenen Versionen - aber das ist mir schon fragwürdig. Sind es wirklich die Tests, die versioniert sind, oder sind es nicht die getesteten Programme, die eine Version haben?
was ist eine Suit? ist das so ein zu testendes Programm?

Also bei mir kommt derzeit noch eine ganz primitive Kaskade als DAtenmodell heraus:

Dabei habe ich die Spalte "Fehler" in "Einzeltest" hineingemacht, als nullable Feld.
Also ein Einzeltest ergibt eine Fehlerbeschreibung (und welche) oder nicht.

gibt es mehrere zu testende softwares, oder bezieht sich alles auf nur eine Software in versch. versionen

also nach deiner erklärung käme ich nun bei sowas raus


Version->TestSuite->Test

da hast du jetzt eine tabelle mit TestSuiten, und in jede kannst du einen haufen tests reinpacken und abfahren. Fehler ist weiterhin ein einzelnes Feld im Test, denn ich gehe davon aus, dass nach Auftreten eines Fehlers der dieser Test nicht fortgesetzt wern kann.
Ich habe Version der TestSuite zugeordnet, weil ich annehme, eine Suite testet nur eine Software-Version

was bedeutet "MEHRERE SUITES testen MEHRERE VERSIONEN."?

Die frage ist, ob eine Suite mehrere Versionen testet, oder ob sie nur eine Version testet. Davon hängt ab, wem Version übergeordnet wird: dem einzelnen Test, oder der ganzen Suite.

Dass die Suite durchläuft ist klar. Nur der einzelne Test kann maximal einen Fehler finden. Deshalb ist Fehler ein nullable Feld von Test.

jdfs. mein Vorschlag.

jut - also version dem Test überordnen.

dabei fällt auf: es müssen Test-Ergebnis-Datensätze generiert werden - das mit meim Fehler als nullable Feld ist zu einfach

zu überlegen wäre, ob die Verhältnisse nicht noch anners liegen, nämlich so:

Suite->Test->Fehler<-Version

also man stellt eine Version ein, und fährt die Suite ab. Im Fehlerfall eines Tests wird ein FehlerDatensatz generiert, der die Version mit angibt.

In diesem Sinne erzeugt ein Test ggfs doch mehrere Fehler, nämlich je nach Version

findich grad sehr plausibel das modell

stevez schrieb:

hab jetzt ein problem mit den beziehungen (siehe anhang oben). Wenn man die beziehungspfeile löscht, bestehen die beziehungen irgendwie trotzdem noch...

das wäre mir neu. - wie äussert sich dieses wundersame "Überleben"?

wie bekomme ich eine Liste aller Tabellennamen im Dataset in eine Combobox?

Ähm - bevor das DAtenmodell nicht geklärt ist, brauchst du keine Combobox zu programmieren.

kannstes endgültige Datenmodell nochmal posten?

ach - du hast immer noch die DB dahinter!

wie gesagt (und wie du siehst): DB-Programmierung ohne Datenbank ist einfacher. Aber weil wassich sage, scheinbar immer nur ankommt, wenn ich groß und fett schreibe: DB-Programmierung ohne Datenbank ist einfacher!

zum Datenmodell:
Versionen ist immer noch plural. aber ein Version-Datensatz ist doch keine Versionen, sondern ist nur eine Version!
Test hat zwar eine Spalte VersionenID, aber keine zugehörige Relation.

Was zum Kuckuck ist nun der Unterschied zw. TestSuite, SuitInhalt, Einzeltest, und Test??

Oder sind Einzeltest und SuitInhalt Altlasten, die weg kommen? Dann entspräche es nämlich so ziemlich meinem Vorschlag.

Übrigens das mit dem doppelten Primkey ist auch für Fehler die vorzugsweise Option. Denn die Identität eines Fehlers ist ja tatsächlich definiert durch den (fehlergenerierenden) Test in verbindung mit der eingestellten Version.

Was bedeutet das Feld "Test.Durchlaeufe"?
Wenn mehrere Durchläufe mit derselben Version geplant sind, dann ist das Datenmodell noch zu einfach. Aber ich hoffe ja, dass ein Test mit einer Version immer dasselbe Ergebnis bringt, und daher nicht mehrfach durchlaufen muß.

Ah - noch richtig Fehler im Modell: Du sagtest ja, dass derselbe Test menrereh Suiten zugeordnet sein kann (und eine Suite hat natürlich mehrere Tests) - also eine m:n Relation, und da fehlt die mittler-Tabelle.

also neu:
Version->Fehler<-Test->TestSuite->Suite

ABer dann muß Fehler natürlich zusätzlich noch angeben, in welcher Suite er entstanden ist, also:
Version->Fehler<-Test->TestSuite->Suite
Suite->Fehler

Fehler hat nun also sogar 3 Foreignkeys auf übergeordnete Tabellen, (die einen dreifachen Primärschlüssel bilden sollten)