Ich habe vor ca. 2 Wochen ein Videotutorial gefunden/gesehen, wo der Sprecher erklärt, wie man ein DataTemplate für eine ListBox erstellt. Er verwendete als Model XBox Spiele, es war also eine Art Vertikale Listbox mit XBox-Spiel Covern. Beim auwählen eines Covers wurde eine kleine Beschreibung zum Spiel mit einem netten kleinen 3D-Effekt dargestellt. Schlussendlich sah es fast einwenig wie ein "Coverflow" aus.
Nur hab ich diesen Link nicht mehr, ich habe in meinem Google-Web-History durchkämmt, Browser-History etc. ich finde diesen Link einfach nicht mehr :(
Evtl. kennt jemand von der Community das Video und kann mir den Link schicken. Das wäre echt super!
das habe ich gemacht und das Ergebniss war bei beiden das gleiche.
Die Daten auf Objekt mappen und dann die Objekte in einer List<objekt> verwalten, finde ich persönlich besser und es entsteht, glaube ich, auch nicht so ein Overhead wie beim DataSet.
Markus
Dieser "Overhead" hat aber auch einige Vorteile, wie zum Beispiel das Suchen, Filtern und Sortieren. Im DataSet sind diese "Features" bereits implementiert, und können mit sehr wenig Codezeilen benutzt werden. Das sind features die Endbenutzer sehr gerne sehen und die usability enorm steigern.
Ich mag den Zugriff auf die Daten mit dem ewigen casten beim Dataset auch nicht wirklich, darum arbeite ich an einer eigenen BindingList<>. SortableeBindinglist habe ich hingekrigt, aber leider ohne advanced sorting. Eine SortSearchableBindingList<> bin ich noch dran, werde meine Ergebnisse auch hier posten. Das Ziel ist es, eine generische BindingList, welche alle grundfunktionen, wie Suchen, Filtern, Sortieren, Laden, Speichern etc. ohne diesen "Overhead" ermöglicht.
- NULL Festlegen -> setzt NULL als FK (wird nix gelöscht, aber Verbindung ist weg)
- Keine Aktion -> Wird wohl ein Fehler Geben und sagen, dass der Parent-Datensatz nicht gelöscht werden kann, da Childs vorhanden
- Überlappen -> Wird wohl Cascade sein
- Standard festlegen -> Ich nehm an: Wie NULL Festlegen, nur kann man anstatt NULL nen beliebigen Wert geben
Gruss,
.unreal
P.S Installier den Manager auf Englisch
edit:
"überlappen"... naja, ich sage mal das ist Cascade weils nix anderes gibt Scheiss übersetzung...
Ich wkenn nhibernate leider noch nicht gut, ich weiss nur dass es existiert Iist etwas dass ich schon seit längerem vorhabe anzuschauen. Darf ich mal unwissend und nicht nachgeforscht Fragen, wie die Darstellung der Daten bei nhibernate funktioniert? Wird Databinding unterstztütz?
Nun ist deine Frage klar . Wir sind hier nicht in einer Anwendung sondern auf der SQL-Server Ebene. Dies ist relativ einfach: Rechtsklick auf eine Tabelle/Modify. Dort im Fenster oben auf Table Designer/Relationships... Das letzte einstellbaren Property mit dem Plus aufklappen, dort kannst du Delete/Update Rule auf Cascade setzen.
Diese Funktion ist mit hoher Vorsicht zu geniessen.
Warum willst du alles neu erfinden? Das DataSet kann dies ja bereits alles, mitels SqlDataAdapter und DataSet.Update() wird Datensatzgenau das entsprechende Query ausgeführt. Zudem werden Diverse Sortier, Such & Filterfunktionen angeboten.
Original von KevinWinter
wenn ich aber ForeignKeyConstrain anlegen will, brauche ich die Info von einer zusätzlichen DataTable
Die brauchst du immer, ansonsten kann dein DS ja gar nicht wissen, ob irgend ein ForeignKey auf dein PrimaryKey zeigt. Wie soll das DataSet sonst wissen, wo eine Relation besteht?
Original von Tokka
Im Skriptum und Lehrbuch sind die Entitäten immer in der Einzahl benannt, aber ob nun einzahl oder mehrzahl ist ja ehr eine "optische" Sache
Ich habe schon sehr viele Scripts in den Händen gehabt, bei denen mir fast die Haaren ausgefallen sind, darum muss das ganz und gar nicht heissen, dass es korrekt ist. Ich kann dir leider nicht mehr sagen, von wo ich diese "Behauptung" habe, vielleicht weiss jemand anders hier in der Community mehr und wird uns belehren.
SELECT * FROM Abteilungen ist in meinen Augen logischer als SELECT * FROM Abteilung.
"Optisch" wäre für mich darum höchstens die Sprache, ob die Entität nun in Englisch oder Deutsch ist.
Zu Frage 1:
Schau dir mal ForeignKeyConstraint.DeleteRule bzw. ForeignKeyConstraint.UpdateRule an. Die ConstraintCollection erreichst du über DataTable.Constraints.
Für mich wirken die Tabellen noch nicht genug Normalisiert.
Um in einem Query auf ein Feld zuzugreifen, würdest du Abteilung.AbteilungID bzw Abteilung.AbteilungsName schreiben. Das ist eine Redundanz! Viel logischer ist Abteilung.ID bzw. Abteilung.Name.
Desweiteren werden Entitäten meines Wissens in mehrzahl geschrieben: Abteilung -> Abteilungen.
Schau dir mal die SqlConnection Klasse an! Die Serverinformationen werden mittels Connectionstring übergeben. Auch wenn Visual Studio sehr viel Wert auf diese Klickbaren Datasources setzt, ich würde das alles mindestens das erste mal von Hand programmieren.
Ich entwickle selbst mit VS.PHP, es ist ein geniales Addin und meiner nach ist es eine der besten IDE für die PHP Entwicklung.
Allerdings stört mich extrem die HTML Intellisense. VS hat eine geniale Intellisense für HTML, allerdings wird bei PHP Projekten eine andere Intellisense verwendet, die um längen schlechter ist. Vieleicht hat jemand eine Ahnung, ob und wie man das umstellen kann?
Der Scope der Setting muss auf User und nicht Application sein, dann sollte das funktionieren. Wenn du die Settings unbedingt von Hand bearbeiten willst, dann drück doch einfach F7, wenn du in der Designermaske der Properties bist. VS bietet einen schönen XML-Editor =)
Es besteht ein DataBinding zwischen deinem DataGridView und deiner DataSource (das DataSet). Änderungen über das DataGridView werden darum automatisch in deinem DataSet "gespeichert". Darum brauchst du nur noch dataset.WriteXml() aufzurufen.
Das Timerzeugs ist absoluter Schwachsinn! Das ist pures gebastel Dies ist doch ein klares zeichen, dass du den falschen Event verwendest. Validating/Validated Event ist GENAU das was du brauchst.
Ansonsten könntest du auch den MausMove event nehmen, und nen Timer drüber, und da überprüfen ob die richtige TextBox ausgewählt ist *grübel*
Original von talla
Okay, ich dachte du bekommst es trotz der Erkenntnis das der Long Wert die Millisekunden ab dem 1.1.1970 sind, nicht hin. Deshalb die klein bissle forsche Antwort, sorry deswegen
Ja, war zuerst ziemlich verärgert über deine Aussage, und wollte entsprechend eine Antwort schreiben. Hab dann aber gemerkt, dass ich mich nicht sehr klar ausgedrückt habe Ist kein Thema mehr!
Zitat
Original von talla
Am Anfang hätt ich beim Long Wert als Datum auch natürlich an die Ticks gedacht
Ich auch Ticks sind Nanosekunden, das könnte man umrechnen lassen, allerdings stimmt auch hier wieder der Startpunkt nicht -> falscher Weg.
Zitat
Original von talla
Mit der Angabe vom Startdatum und das der Wert die seit daher vergangenen Millisekunden sind, ist die Diskussion doch gegessen oder? Einfach den Wert als Millisekunden aufaddieren und fertig.
Ja, sie war eigentlich für mich gegessen, darum hab ich geschrieben "Habs rausgefunden".
Zitat
Original von norman_timo
Die Frage ist eher, woher hast Du Deinen Long, denn bei dieser Quelle musst Du nach Hilfe suchen, nicht bei dem DateTime...
Kommt aus einem Log einer Java-Portalsoftware. Es existieren auch keine Defintionen Mir sind da die Hände gebunden, kann nur nehmen was da ist
Zitat
Original von svenson
Ist allerdings schön blöd
Es gibt noch dooferes: Bei Visual Basic (nicht .NET) steht der Wert 0 für den 30.12.1899. Super Idee! Excel beginnt einen Tag später, beim 1.1.1900. Wie bereits gesagt, der UNIX Timestamp beginnt bei 1.1.1970.
Original von talla
Ist es so schwer sich mal in der Doku anzuschaun was für Funktionen DateTime bietet? Erstell dir nen DateTime mit dem 1.1.1970 als Datum und addiere einfach die Millisekunden hinzu.
Ich habe vieliecht die Frage nicht richtig Formuliert. Ich wusste nicht, ab wann der Long anfängt (-> 1.1.1970), und ob es wirklich Milisekunden sind. In der MSDN findest du nix von Datum als Long, diese Definitionen habe ich in der Javadokumentation gefunden. Mit diesen Definitionen ist es ein Kinderspiel, aber eben ohne gehts nit.
In der Aktuellen dot.net Magazin Ausgabe hat es 4 Seiten "Alles was man über Interface wissen muss". Kann diesen Artikel nur Empfehlen, wobei ich den Preis des Magazins in der Schweiz (umgerechnet: 11€) zu teuer finde.
BindingSource ist "nur" eine Hilfsklasse, du kannst auch direkt binden ohne BindingSource (empfehle ich dir nicht).
In der MSDN hat es einen Artikel namens "How to: Create a Master/Detail Form Using Two Windows Forms DataGridView Controls ". Such mal nach dem Artikel!
Zitat
Langt es zu wenn ich da nur einen Dataset einer Grid zuweise oder muss ich da mit Bindingsource arbeiten?
Wie im Artikel ersichtlich ist, bindest du das zweite DataGridView an die Relation (-> dataset.Releations.Add(...)), ob du da ein BindingSource verwendest oder nicht, spielt keine Rolle. BindingSource vereinfacht vieles, da man z.b besser auf den currencymanager zugreifen kann.