Suchergebnisse

es gibt viele Internet-"MySql"-Datenbanken, die gar keinen Zugriff per DbConnection zulassen, sondern nur iwas über Php. (Imo sollte man diese "Php-Datenbank" nennen, nicht MySql ) auf DbGenerator ist ein lauffähiges Sample dabei, was auf eine wirkliche MySql auf kassaserver.com zugreift. Damit kannste üben, und hast auch eine Vorlage, die funktioniert.

Zitat von Nils_Kr: „das ist keine Internet-DB sondern eine DB, die für Versuchszwecke für mich aufgesetzt wurde. Von daher sollte eine Verbindung auch außerhalb PHP möglich sein. Gibt es im Internet eine MS SQL DB mit der man testen kann? Das verlinkte Programm ist mir zumindest momentan noch zu unübersichtlich.“Tja, Pech. Im dortigen Download ist ja eine (leere) SqlServer-Db mit dabei. Von daher weiss ich jetzt nicht, warum du noch sonstwo im Internet eine suchst, und inwiefern das übersichtlic…

Also ist wirklich so, dass du denen jede Spalte genauestens beschreiben musst, und die machen die dann in die DB? a) haben die sonst nix zu tun? b) ist annähernd ausgeschlossen, dass die das auf Anhieb richtig hinkriegen c) Es kommt nicht vor, dass eine Db im Verlauf einer Anwendungs-Entwicklung nicht mehrmals geändert werden muss - wollt ihr da jedesmal das Theater von vorn durchziehen? d) au backe! Also bis eure Bürokratie das gemahlen bekommen hat, so lange kannst du doch versuchen, dir selbs…

in welchem Beispielprogramm? Meinst du beim DBGenerator? Naja, guck immer einfach ins MainForm - alles annere brauchst du nicht zu verstehen - sind üblicherweise kaum mehr als 10 Zeilen - und sind selbsterklärend bzw. werden durch Intellisense erklärt. Das gilt für die Sample-Projekte, der DBGenerator selbst ist natürlich wesentlich aufwändiger gecodet.

was soll ich sagen? DbExtensions hab ich dir ja schon vor zig Posts empfohlen, da ist eine Extension drin, die geht so:VB.NET-Quellcode (1 Zeile)und das Dataset ist komplett befüllt. Es sind weitere Extensions drin, mit denen man auch einzelne Tabellen befüllen kann, auch mit selektiver Befüllung, und auch gefilterte Befüllung, aber erstmal voll machen geht wie gezeigt. auch, und eine annere Extension ist auch drin:VB.NET-Quellcode (1 Zeile)und gespeichert ist. Also imo einfacher geht's nicht. W…

post#4 und weiterführende Links

Also gelegentlich verhaspelt er sich. Dann failt das Code-Generieren, und es entstehen mehrere Hundert Fehler. Lösung: die Dataset.Designer.VB komplett ausschneiden, wieder einfügen, neu kompilieren. Falls das nicht hilft: die Designer.vb. löschen, und im Designer nur ein bischen eine Tabelle verschieben, sodass der Code neu generiert wird. Also finde ich noch einfach zu handeln, weil wenner sich verhaspelt, sind das typischerweise gleich 102 Fehler (offenbar das Error-Report-Maximum) - da weiß …

komisch. Nach meinen Versuchen müssen Hilfs-Projekte ein niedrigeres oder gleiches Framework nutzen wie das Haupt-Projekt. Folglich gehe ich davon aus, dass du beim Zusammenbinden was falsch gemacht hast. Also die Haupt verweist auf die Helpers, nicht umgekehrt. Und dann geht das. Oder mach ein Sample, was den Fehler reproduziert, und hängs an, aber ohne Binaries.

nein, DbExtensions nutzt intensiv die WinForms und die GeneralHelpers. Das ist quasi eine Schichtenarchitektur, vom Einfachen, allgemeingültigen (general) zum Anspruchsvollen, spezialisierten (DB). Eine ObjectBrowser-Suche inne Sample-Solution hätte dir übrigens aufgezeigt, wo die als fehlend benannten Begriffe zu finden gewesen wären.

bei mir tun die mit Strict On. Ich würd dir empfehlen, nimm da keine Veränderungen vor, sondern orientiere dich am video und an den Beispiel-Codes, die zeigen doch, wie's geht. Wenn das nicht so funzt, wies ist, dann benutzt du es falsch, und wenn du dann den Code änderst oder so Grundeinstellungen wie Option Strict, machst dus nur schlimmer. Aber ich kann dir auch eben ein Beispiel basteln, wenn dir das nicht zu doof ist. Weil das Beispiel wird nur daraus bestehen, in einem beliebigen dortigen …

was willst du probieren? Wenn du die PersonBerufApp.zip vom DbGenerator-Thread downloadest, entpackst, im VS öffnest und startest - läuft das oder welcher Fehler kommt? Ich habs grade probiert, und es kommt der Fehler, dass der Pfad zur DB nicht stimmt, was ja wohl logisch ist, den muss man anpassen auf die SqlCe_FW4.sdf an dem Ort, wo sie hin entpackt wurde.

du meinst also, eine passende Db händisch aufzusetzen, und alle Zugriffs-Routinen selbst zu coden wird einfacher werden, als den Fehler zu beseitigen, der scheinbar beim Einbinden der DbExtensions vorliegt? Das ist sehr sehr viel individuelle Arbeit, mit DataAdaptern, DbCommands, DbParametern, CommandBuildern, und die Tabellen sind auch in der richtigen Reihenfolge fürs Einlesen einzulesen, und in der anderen richtigen Reihenfolge fürs Rückspeichern rückzuspeichern. Und viele naheliegende Vorgeh…

ah - evtl. hast du das Projekt eingebunden, und nur nicht kompiliert! Zitat von Nils_Kr: „klang es eher so, dass das mit der DB-Verwaltung eher easy ist“wer will dir sowas weismachen? Wenn das easy wäre, warum rate ich dann immer, das auf später zu vertagen? Mitte DbExtensions ists auch so easy wie möglich, dafür hab ich mir in > 5000 Zeilen Code alle erdenkliche Mühe gegeben

jo, deine Vorgehensweise ist richtig. Allerdings den richtigen Connectionstring kann ich dir auch nicht vorsagen Ah - SqlServer ist was anneres als SqlCompact (SqlCe)! Du musst also eine ProviderFactory aussm Namespace SqlClient angeben!

eine Zeile "heißt" nicht. und wenn der Compiler sie nicht schon im Editor bemeckert, dann isse wohl richtig. Wenn du das Gefühl hast, die wird ühaupt nicht erreicht vom Code, dann setz mal einen Haltepunkt drauf. Haltepunkt und Einzelschritt-Modus sind dir bekannt? sonst gugge VisualStudio richtig nutzen (Google ist nicht deine Mami)

Und das mit dem Haltepunkt - wieso gehst du darauf nicht ein? Jedenfalls scheinst du die DbExtensions falsch zu bedienen, weil dein System ja ansonsten funktioniert. vlt hast du ja versäumt, den Dataset.Fill-Befehl aufzurufen?

Dassis von mich: DBExtensions - allgemeine Lösung der Daten-Persistierung via Datenbanken

also wie ich bereits vor 1 Woche vermutete:Zitat von ErfinderDesRades: „vlt hast du ja versäumt, den Dataset.Fill-Befehl aufzurufen?“ probierma so:VB.NET-Quellcode (5 Zeilen) Ah - vmtl hast du das Tut zu DbExtensions auch gar nicht gelesen - weil ein Ziel der DbExtensions ist ja, die generierten Tableadapter üflüssig zu machen, und sofort im Dataset-Designer wieder runterzuschmeißen:Zitat von ErfinderDesRades: „Und auch: "tschüss, TableAdapter und TableAdapterManager!" - ihr werdet ab sofort gle…

prima! Und hast du auch die generierten TableAdapter aus dem DatasetDesigner rausgeschmissen?

Das kann ich mir nur so erklären, dass die neue Datatable nicht Teil des typisierten Datasets ist. Vlt. hast du stattdessen ein weiteres Dataset angelegt, das kann mein DatasetAdapter ja nicht wissen.

entweder frage dich: wieviele Tabellen zeigt der Dataset-Designer? oder frage dich: wieviele Dateien mit Endung .xsd enthält mein Projekt?

dann liegts nicht daran. Hat die neue DataTable einen Primärschlüssel? (aber ein Fehlen sollte eiglich eine Exception verursachen) vlt. postest du nochmal den kompletten Code der Konfiguration des DatasetAdapters. Vorzugsweise die ganze Methode.

wird geöffnet, synchronisiert, wird geschlossen - was sonst?

man kann bei der Initialisierung eine Dataset-Extension Dataset.Persist(true, paramArray DataTable()) aufrufen, mit der konfiguriert wird, dass bestimmte Tabellen persistiert werden, andere nicht. Mir ist aber, als hätte ich das beim Download-Thread erwähnt.

willst du mal versuchen, die Bedeutung des ParamArray-Schlüsselwortes selbst zu recherchieren? Weißt du, wie man die Auflistung der Schlüsselworte direkt auf MSDN auffindet, mittm ObjectBrowser? Ansonsten VisualStudio richtig nutzen (Google ist nicht deine Mami) Und ich sprach von Dataset.Persist(), nicht Dataset.Adapter.Persist - das gibbets nicht. Vlt musst du dir auch erarbeiten, was Extension-Methods sind. Also du solltest dich knowhowmäßig instand setzen, eine angegebene Methode aufzufinden…

Zitat von Nils_Kr: „Wenn ich das mache, werden die Daten aber nicht mehr geladen.“Glaub ich nicht. Und die Syntax deiner 2. Zeile dürfte nicht kompilieren.

ah - ja natürlich! Persistieren bedeutet "Laden und Speichern". Da hab ich dich falsch verstanden wenn du einerseits laden willst, speichern aber nicht. Das Speichern einer DataTable überspringt man mittels DataTable.AcceptChanges. Das setzt alle RowStates auf "Unchanged", und unchanged DataRows schicken die DataAdapter nicht an die DB. Aber normalerweise sollte VB.NET-Quellcode (1 Zeile)nicht durchlaufen oder was ist .archiv2() für eine Ding? Das müsste ja eine Methode sein, oder? Edit: Potzbli…

ja - das meinte ich in post#72

Sehr empfohlen ist, immer das ganze Dataset zu synchronisieren. So Spässchen wie eine Tabelle zwar aus der DB befüllen, beim Speichern aber nicht zu berücksichtigen, sind hochriskant, weil der Client dann mit anderen Daten arbeitet, als tatsächlich in der DB drinne sind. Und ich verstehe auch gar nicht, was du damit bezweckst. Zitat von Nils_Kr: „nur bestimmte Teile der Datenbank mit den DataSets zu synchronisieren? z.B. alle Datensätze aus einem festgelegten Zeitraum.“Das ist ziemlich irre, jdf…

Zitat von Nils_Kr: „Die Daten die nicht zurückgespeichert werden sind sowieso "readonly" es gibt im Programm selbst keine Möglichkeit die Daten zu bearbeiten,“Wenn du die Daten nicht änderst, brauchst du dich nicht drum zu kümmern. Die Änderungsverfolgung des Datasets gewährleistet sowieso, dass ungeänderte Datensätze auch nicht rückgespeichert werden - aber das hast du doch bereits gewusst .