Suchergebnisse

ich kann dir nur empfehlen: Lass das erstmal mitte Datenbank. Für so Kleinkram fährst du mit Dataset-Only viel besser, und gewöhnst dir gleichzeitig einen sauberen Programmierstil an: vier Views-Videos Bestimmte Sachen suchen dann einfach mit Linq aus dem Dataset. Linq ist ähnlich Sql, nur hilft dabei Intellisense, während du in sql jeden besch... Fehler erst beim Testlauf erfährst, und auch noch mit so total unverständlichen Meldungen. Wirklich: wenn du das bis zur Abgabe noch fertig kriegen wi…

Zitat von DonQuijote: „Ich habe knapp 1200 Datensätze also so Kleinkram ist das wieder nicht. Außerdem wollte ich eh das lernen und ich bin ja schon auf einem guten Weg.“Doch, das ist Kleinkram. Man kann anfangen, über Dbs nachzudenken, wenn die Größe des gespeicherten Datasets - wasweissich - 20 MB überschreitet. Das sind vlt. - die Schätzungen streuen natürlich enorm - 20000 Datensätze. Also da kann man dann anfangen, es zu überlegen - muss aber nicht. Ich empfehle, immer erst ohne DB zu entwi…

wie gesagt: du brauchst keine Datenbank. Folge doch bitte bitte mal den gegebenen Links und versuche den Gedanken zu folgen, die zu dem unerhörten Ergebnis kommen: Datenbänkerei braucht mitnichten immer eine Datenbank! Folge den Gedanken, die darauf führen, dass man die Datenbänkerei im Gegenteil besser erlernt, wenn man zumindest zunächstmal ohne DB entwickelt! Ja, ich weiß, das ist ein so unerhörter Gedanke, dass es nur wenige gibt, die ihn bereits verstehen, wenn man es ihnen nur einmal sagt.…

ja, damit kannst du doch schon einen einfachen ParentchildView (Technologie->datenbank) bauen (wie in 4Views gezeigt), und dann kannst du auch schon Daten eingeben. Mir stößt halt die schwammige Benamung auf: ein Dataset mit dem nichtssagenden Namen dataset, und darin eine Tabelle mit dem sogar irreführenden Namen Datenbank - da fängts gleich an, dass das Datenmodell sich noch verändert während der Entwicklung. Für welchen Problemkreis zu bearbeiten schreibst du das Programm? So soll das Dataset…

wahrscheinlich nicht. Comboboxen werden eingesetzt, um diskrete Möglichkeiten komfortabel als Auswahl zu präsentieren. Logisch müssen diese diskreten Möglichkeiten in eigenen Tabellen angelegt sein. etwa in 4Views gibts Comboboxen, mit denen von einem Artikel der Lieferant ausgewählt wird, oder die Kategorie, zu der er gehören soll. Aber auch das ist Datenmodellierung: Du musst konkret sprechen. So abstrakt mit "gewisse Parameter" und bla - daraus kann man kein Datenmodell ableiten.

ja, das sind m:n - Relationen: Du brauchst die Tabellen Einsatzgebiet, Kraftanlage, Technologie, und dann brauchst du eine Zuordnungs-Tabelle, deren Datensätze je ein Einsatzgebiet mit einer Kraftanlage mit einer Technologie verknüpfen (ForeignKeys). Auf diese ZuordnungsTabelle kannst du dann einen 2-fachen Filter setzen, nach KraftAnlage und EinsatzGebiet, und übrig bleiben die Zuordnungen, die eine Technologie genau dieser Combi von KA und EG zuordnen. Also es ist bisserl über m:n hinaus, weil…

es ist alles in 4Views gezeigt, von Adam und Eva an. in 4Views ists die beispielhafte m:n - Relation Kategorie->Artikel<-Lieferant Setz doch dasseslbe erstmal mit Einsatzgebiet->Zuordnung<-Technologie um weitere Kriterien-Tabellen kann man ja noch dranmachen, also Tabelle + Relation, etwa KraftAnlage->Zuordnung

eiglich gibts da nix zu dokumentieren. ein typDataset im Dataset-Designer dokumentiert sich selbst. (ähm - das gilt nur für Kleinkram, so ab 10 Tabellen und trickreicheren Modellen muss man sich doku-mäßig wirklich Gedanken machen ) Du kannst mal Screenshot posten

ja, ist super! kriegst du schon laden und speichern mit Dataset.WriteXml hin? eine Helpers-Dll, die alle möglichen Fußangeln umgeht, gibts in Daten laden, speichern, verarbeiten dazu musst du lernen, überhaupt ein HelpersProjekt einzubinden: Helper-Projekt einbinden Was eh zu lernen mittelfristig unvermeidlich ist. @sonne75 : Keine Ahnung. Ich hab MS mal vorgeschlagen, ein "Comment-Behind" in ihren DatasetDesigner zu integrieren. Sodass man auf Tabellen, Spalten, Relationen zeigen oder rechtskli…

bist du meim zum Thema gegebenen Link gefolgt?

ja, ist viel, aber du schaffst das schon Du lernst halt programmieren. Da ists stinknormal, eine Dll einzubinden. Du musst den Code ja nicht verstehen (bei anners eingebundenen Dlls erhälst du nichtmal Einblick). Dlls sind zum Benutzen da, nicht zwingend zum Verstehen - Du benutzt ja auch die System.Windows.Forms.Dll. (Annererseits kann man aus einer OpenSource-Dll enorm was lernen.)

ja - ist viel. "PersitData.DataSet1" ist der vollqualifizierte Name des Datasets meines Beispielprojekts. Code-Namen sind ja immer ineinander geschachtelt, meist in Namespaces. Ist ein Namespace importiert mit der Imports-Anweisung oder auf Projekt-Ebene, dann braucht man die Klassen nicht mehr vollqualifiziert zu benennen. Aber die Imports-Anweisung muss immer vollqualifiziert benennen, und der Namespace, in den bei meim Beispiel das Dataset1 eingeschachtelt ist, ist der sog. RootNamespace mein…

nein. Statt Imports PersistData.Dataset1 schreibst du deinen Rootnamespace, und dein typisiertes Dataset hin: Imports DredgersFinal.DredgersDts aber ich seh grad auffm Bilde - was hast du denn da gemacht: Jetzt haste da ein ganz neues Project namens ClassLibrary1 angelegt, und da iwelchen Code von mir eingepastet, aus dem Form im Zustand, bevor meine Dll eingebunden war. Also das Projekt bitte löschen. Keinen Code schreiben oder herumkopieren. Deine Solution nehmen, wo dein Project drinne ist, u…

Zitat von DonQuijote: „Versteh ich das richtig...“ja - wie sollte man es sonst verstehen? Du hast allerdings noch das Registrieren vergessen. Das schützt gegen einige WinForm- und Dataset-Bugs, die manchmal (nicht immer) auftreten. Besser machs gleich, dann bleiben dir erhebliche Verwunderlichungen im später fortgeschrittenen Projekt erspart.

hmm - wenn du mal in mein BeispielCode gucken tätest - ich find das mit dem Registrieren nicht zu übersehen:VB.NET-Quellcode (10 Zeilen) Das mit deim klein Fehler weiß ich auch nicht. Ich weiß nur, dasses keine kleinen Fehler gibt. Vermutlich ist das Dataset verdaddelt. Also dass die generierte Klasse anders heißt als DredgersDts. Sowas kommt vor, wenn man eine Dataset-Datei einfach in ein anneres Projekt kopiert. Ah - guck mal in den DesignerCode von deim DredgersDataset! Da ist bestimmt noch d…

wie lautet denn die Fehlermeldung?

ja, dann zieh doch mal eins aufs form drauf

mach erstmal einen RawView, der einfach alle Tabellen anzeigt - ausser die Zuordnung. Dann kannst du schonmal Sachen eingeben. Für die Zuordnungen musste einen JoiningView basteln, für jeden ForeignKey ist eine ComboboxColumn ins DGV zu basteln. Diesen JoiningView kann man im nächsten Schritt auch filtern wie man will.

noch ein Tipp: meine Dll speichert die Daten unter "DredgersDts.xml". Ist manchmal nützlich, wenn du diese Datendatei deinem Projekt hinzfügst. (Projektexplorer "Alle Dateien anzeigen", dann Kontextmenü-hinzufügen). naja, vlt. nicht wichtig, aber ist nett, weil dann kann man in die Datei auch reingugge.

zunächstmal da, wo sie derzeit ist. Du kannst den Speicherort aber auch explizit festlegen. Beim Setup später ist dabei auch noch zu beachten, dass Windows für eine installierte Anwendung bestimmte AppData-Ordner bereithält - aber bis da ist noch sooo lange hin.

Alle möglichen von Windows vordefinierten Ordner kannste per Environment.SpecialFolder zur Laufzeit abrufen. Davon ist AppData oder LocalAppData glaub besonders interessant, weil in diesen Ordnern hat eine Anwendung Schreibrechte.

Was kannich darauf antworten, als: "was denn sonst?" Du kannst übrigens mal eine Volltextsuche nach "SpecialFolder" machen - ich glaub, ich hab bereits eingebaut, dass unter Release-Kompilation in Windows-Ordner gespeichert wird. ach nee - ich hab nicht SpecialFolders verwendet, sondern Application.LocalUserAppDataPath eingebautVB.NET-Quellcode (12 Zeilen)

von Setupsen hab ich kein Schimmer. Ich glaube aber, es ist möglich...