Suchergebnisse
Suchergebnisse 1-25 von insgesamt 25.
Hier erfahren Sie, wie einfach Sie Ihren Browser aktualisieren können.
-
ich sag ja immer: DatasetOnly entwickeln, die DB erst zuletzt unterschieben. paar tausend Datensätze sich auch nicht sonderlich erschreckend viele. Hier läuft es dann wohl drauf hinaus, wenn das neue Proggi fertig ist, was mit einer anneren DB-Struktur arbeitet, dann eben die ollen Tabellen auszulesen und neue Datensätze in der neuen DB zu generieren. Das mit dem TableAdapter im Designer anlegen für eine DB, dies so noch gar nicht gibt, hab ich ühaupt nicht verstanden. Die TableAdapter im Design…
-
ich weiß nicht, ob das genau ist, was dir vorschwebt, aber natürlich kann man codeseitig ein untypisiertes Dataset aufbauen, erweitern, durch-gestalten, mit allem Pipapo. Natürlich generiert das nicht die typisierten Wrapper-Funktionen, und es existiert halt nur zur Laufzeit, d.h. Bindings ans Gui muss man dann auch per Code setzen, ohne Designer-Unterstützung. Aber es gibt die Methode DAtaset.WriteXmlSchema, die generiert eine .xsd - Datei, die man dann auch im Dataset-Designer laden kann, und …
-
die Standard-Einstellung mit -1 ist durchaus sinnvoll. Das Abspeichern von Autowert-Feldern in eine DB ist ziemlich speziell, denn nach jedem Insert muss ein Select nachgeschossen werden, der den von der DB generierten Autowert abfragt und ins Dataset einpflegt. Die Konvention dabei ist, dass das Dataset negative Autowerte generiert, die DB aber positive - auf diese Weise kommen die sich nicht in die Quere. schaffst du mit Access? dann sähe das Select nachschiessen ungefähr so aus: Autowerte ins…
-
ja, magst du recht haben. Ich erzähl halt das Prinzip (Select nachschießen) und die Vorgehensweise für Standard-Fälle. Wenn sie da iwas "exotisches" machen muss - tjaaa... Jedenfalls am Prinzip gehts nicht vorbei, es sei denn man nimmt System.Guid als Primkey-Datentyp, aber das belegt glaub 10fachen Speicher und ist auch langsamer im Abruf (dafür aber schneller im Insert).
-
ja, jetzt hab ich aber ausnahmsweise nicht von DatasetOnly geredet, sondern wie man tatsächlich Autowerte vom Dataset in eine DB speichert. Ich bin ja selbst der Exot mit meim ständigen DatasetOnly - Otto-Normal-Datenbänker ist immer ganz vonne Socken, wenn ich damit komme, dasses ohne DB doch viel einfacher ist. Also der Standard-Standard, wie Ado.Net konzipiert ist, ist, dass man aus einer DB ein typDataset generiert, und mit den generierten TableAdaptern befüllt/zurückspeichert. Bei SqlServer…
-
also wenn du das Dataset komplett füllen willst - heißt das, du willst DatasetOnly arbeiten? Dann hast du natürlich keine DataAdapter, denn es gibt keine DB, die zu adaptieren wäre. Das einfachste: Daten laden, speichern, verarbeiten - weiter unten ist auch die Lösung mittm formübergreifenden Brimborium
-
hmm. weil normal, wenn man eine DB komplett in' speicher lädt - laden kann, dann ist DatasetOnly eiglich einfacher.
-
DBExtensions Da ist eine Extension dabei: Dataset.Fill() - und befüllt ist. Und da ist auch die Dataset.Register(Form)-Extension dabei, für formübergreifendes Databinding. @Noyne:: ich hoffe, du weißt, was Extensions sind, ansonsten jetzt der rechte Zeitpunkt sich schlau zu machen, denn vmtl. deutlich geworden: Extensions sind nützlich
-
ja Wenn man dem Dataset einen DatasetAdapter "mitteilt", dann hat man eine Verbindung zur Datenbank, ansonsten greift der XmlDatasetAdapter. Die Dataset.Fill()-Extension untertützen aber beide - das ist bereits in DatasetAdapterBase geregelt.
-
Helper-Projekt einbinden und grundsätzlich ist wurst, in welchem Ordner die Helper-Projekte liegen. Es ist allerdings sinnvoll, sie nicht direkt in den einzelnen Solution-Ordner zu packen, sondern als eigenständige Ordner. Weil vonne Idee her sollen diese Projekte ja auch in andere Solutions eingebunden werden. Aber die SampleSolutions sind doch bereits in dieser Weise aufgebaut, also das müsste man doch nachbauen können. Und weggehen tun die Fehler erst, wenn man einbindet, richtig verweist, un…
-
sonst schmeiß halt das SqlCe-Projekt raus. Wundert mich nur, ich hätte gedacht, SqlCe sei bei FW4 mit OnBord. Eher hätte ich Probleme mit SqLite erwartet. Es sind halt für verschiedene DB-Provider Samples drinne. Du kannst auch im Dateisystem in die einzelnen Ordner gehen, da gibts auch individuelle Solution-Files. Also im Access-Ordner etwa ist ein SolutionFile drin, was nur das Access-Projekt mit den Helpers zusammenbindet, und im SqlServer-Ordner ist ein SolutionFile drin, was nur das SqlServ…
-
die Registrierung ermöglicht u.a. formübergreifendes Databinding. Auch bügelt sie einen WinForms-Bug weg, der manchmal beim Schließen eines Forms mit komplexer gebundener Oberfläche auftritt. Einiges dazu in Daten laden, speichern, verarbeiten
-
Zitat von sonne75: „musst du der Fill() natürlich sagen, womit sie es füllen soll.“nee - muss sie nicht - das ist bereits über den Extension-Mechanismus erledigt, dasser weiß, dasser das Dataset füllen soll. Das Problem ist denke ich die unterschiedliche Prozessor-Architektur der Projekte - das muss einheitlich. Ich nehme immer "AnyCpu", und hoffe, das sei am kompatibelsten. Aber ich dachte in Helper-Projekt einbinden sei das iwo erwähnt - entweder im Film oder in den Posts.
-
und du hast1. alle Projekte in einer Solution eingebunde 2. in der Hauptanwendung Verweise auf die Helper-Projekte gesetzt ? Aber der beim Tut beiliegende Sample-Code funktioniert? kannst du eine Sample-Solution zusammenzippen, die den Fehler reproduziert? Bitte ohne den bin - Ordner.
-
Zitat von Noyne: „Zitat von ErfinderDesRades: „Aber der beim Tut beiliegende Sample-Code funktioniert?“Kann ich dir nicht sagen, ich hab die Projekte direkt in meine Projektmappe eingefügt ...“ Dann probier das doch mal als erstes aus. Und vlt. nicht die AllTogether-Solution, sonder erstmal die Access-Solution im AccessTest - Ordner. Weil das ja mit SqlCe iwie komisch zu sein scheint auf deim System. Anleitung (Bild-)DateiAnhänge
-
wo kommt denn da nu die HelpersSmallEd her? also wenn du das grosse Programm einbindest mit GeneralHelpers, WinformHelpers, DBExtension, dann solltest du nicht auch noch die HelpersSmallEdition einbinden, denn dann hat man natürlich allerlei Dinge doppelt gemoppelt, und bekommt logisch den Fehler: Fehler 7 Fehler bei der Überladungsauflösung, da keine zugreifbare "Fill" für diese Argumente am spezifischsten ist: In "System.Data.DatasetX" definierte Erweiterungsmethode "Public Sub Fill(ParamArray…
-
so, jetzt hab ichs auch nochmal runtergeladen, und fand, dass du scheinbar eine veraltete DB-Extension-Version nutze tust - wo hast du die her?
-
ja, aber die allTogether2010.zip ist inzwischen bisserl verbessert. Und das ist komisch, denn dein Code will mit 2 Parametern registrieren (was der neuen Version entspräche), aber die Helpers sind noch auf dem Stand, der nur einen Parameter erwartet.
-
wie gesagt: Eine Verbindung zur DB hat man erst, wenn man dem Dataset einen (zuvor zu erstellenden) DatasetAdapter "mitteilt". Geschieht das nicht, greift der XmlDatasetAdapter, und wenn der keine Dataset-xml-Datei vorfindet, sagt er das halt. Läuft inzwischen mal eines meiner Samples bei dir? Dann hättest du doch eine Vorlage.
-
tja - ich weiß auch nicht... geht das denn?
-
ups - gugge mein Edit von #74
-
ah - änder mal den ConnectionString in den Settings auf Provider=Microsoft.ACE.OLEDB.12.0;Persist Security Info=True; Data Source=|DataDirectory|\BestellungPrim.MDB Jet-OLEDB 4.0 ist veraltet.
-
und mal projektmappe erstellen?
-
das, welches behauptet, eine Assembly sei nicht vorhanden.
-
tja, keine Ahnung. Dein Anabox-Teil habich jdfs. trotz alter Version mit nur einer Zeile Code ans Laufen gebracht