Dataset, TableAdapter im Designer erstellen - Problem mit angebundener Access-DB

  • VB.NET

Es gibt 84 Antworten in diesem Thema. Der letzte Beitrag () ist von Noyne.

    Dataset, TableAdapter im Designer erstellen - Problem mit angebundener Access-DB

    Hallöchen Leute ...

    Ich hätte wieder mal ein Problemchen ...

    Ich bin gerade dabei, eine Software zu schreiben, mit der Pflegeheime ihre Bewohner mit ihren Medikationen verwaltet können. Dabei können ebenso die Angehörigen der Bewohner, Heimmitarbeiter, diverse Apotheken und Ärzte angelegt und Bestellungen bei letzteren gemacht werden.

    Die Daten werden in einer Access-DB gespeichert. Momentan erstelle ich meine Datasets zur Laufzeit, wollte sie aber gern schon zur Laufzeit mit TableAdaptern anlegen.
    Vor mehr als 10 Jahren wurde von einer externen Firma die Software erstellt, auf der mein Programm aufbaut. Die alte Software mitsamt der alten Access-DB werden heute noch genutzt, d.h. die DB enthält ein paar 1000 Datensätze von Bewohnern, Medikamenten, Bestellungen und Medikationen.
    Mein Programm hat einige Erweiterungen (und bekommt auch noch welche) und meine Access-DB hat sich dem entsprechend mitentwickelt – einige Felder sind hinzugekommen oder haben ihre Datentypen getauscht (z.B. von Integer in String), eine Tabelle ist komplett umstrukturiert und eine ganz neue ist mit dazugekommen.
    Da die Datensätze aus der alten Access-DB erhalten werden müssen(logisch, mit denen wurde ja bis eben noch gearbeitet), hab ich mein Programm so aufgebaut, dass es ganz am Anfang die alte DB kopiert (zur Sicherheit) und danach die gewünschten Datenbankänderungen vorgenommen werden.

    Das Problem ergibt sich jetzt bei dem Dataset. Wie schon erwähnt wollte ich gerne mit TableAdaptern arbeiten. Bei denen muss man aber angeben, welche Tabellen aus der Datenbank dran gebunden werden sollen. Allerdings geht das schlecht, wenn die Tabellen noch nicht umgebaut sind oder noch gar nicht existieren.
    Rein theoretisch bleibt mir dann ja nichts anderes als die Datasets zur Laufzeit zu erstellen.

    Oder hat jemand eine Idee, wie ich trotzdem im Designer schon die TableAdapter erstellen könnte obwohl die geänderte DB „noch gar nicht existiert“ (wird ja erst beim 1. Programmstart erstellt)?

    Die Ideen, die ich hatte, waren folgende:

    1. Den Kollegen, die mit dem alten Programm arbeiten, meine neue Datenbank unterzuschieben (also jetzt hin zu gehen, die neue DB anstelle der alten einfügen und hoffen, dass das alte Programm trotzdem funktioniert, auch wenn ich an den Tabellen rumgeschraubt habe – was unwahrscheinlich, aber testenswert wäre …)
    2. Weiter mit zur Laufzeit erstellten DSs arbeiten (obwohl das verdammt unschön ist)

    Ich hoff, ich konnte mich einigermaßen klar ausdrücken ...

    Danke für eure Hilfe,
    Noyne
    Your computer is running... You better go chase it! :P :D
    Momentan erstelle ich meine Datasets zur Laufzeit, wollte sie aber gern schon zur Laufzeit mit TableAdaptern anlegen.

    Ich glaube, es wird bei dir Zeit auf ein typ. Dataset umzusteigen und dein Datenmodell auf die neuen Anforderungen anzupassen.
    Nach deinen Angaben nach, vermute ich, dass du dein Datenmodel in der AccessDB modifiziert hast - aber kein passendes typ. Dataset in deiner Anwendung vorliegen hast...
    Im folgenden Thread wird besprochen, wie ein typ. DataSet an eine geänderte DB angepasst werden kann:
    Access-Datenbank geändert
    Und hier wird besprochen, wie ein typ. DataSet an Hand einer bestehenden DB erstellt wird:
    Möglichkeit um Datenquelle einzubinden
    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 Designer sind doch eh völlig uninteressant - wichtig sind doch die DataTables.
    Guten Morgen ^^

    Hm, danke erstmal für eure Antworten.

    Ich bin gerade am Überlegen ...

    Vielleicht schreib ich euch mal auf, was mir gerade durch den Kopf geht....

    Die Original-Access-DB und das Original-Programm, mit denen meine Kollegen gerade arbeiten, sind weit über 10 Jahre alt ...
    Über den Entwicklungsprozess meiner Software hinweg habe ich Änderungen an genau dieser Datenbank über mein Programm vorgenommen (Ich habe ein Startform, welches schaut, welche Version die DB gerade hat. Wenn es eine alte DB ist, werden über SQL-Befehle die Felder angepasst, Tabellen hinzugefügt usw.).
    Da ich mir einiges (vor allem vom ErfinderDesRades ;) ) zu typisierten DataSets angeguckt hatte, wollte ich eh gern komplett auf typisierte DS umsteigen ...

    Die 10 Jahre alte DB als Dataset hinzuzufügen seh ich nicht als Problem (da hat mir VB1963 schon mal in einem anderen Thread geholfen). Da weiß ich, wie ich's angehen muss.

    Eine neue Frage dazu:
    Ist es möglich (so wie ich es jetzt noch mit der DB mache), das Dataset im Programm anzupassen, sodass es so aufgebaut ist, wie ich es am Ende brauche?
    Gibt's da Funktionen? Hinzufügen/Löschen von Spalten/Tabellen??

    ---------------------------------------------------------------------------------

    Eine andere Alternative, die mir im Moment durch den Kopf geht:
    Ich habe ja das Original-Programm (das 10 Jahre alte) nachgebastelt und das läuft an sich auch gut und anscheinend auch mit der ganz neuen Access-DB (das muss ich aber erst mal richtig testen!!) Wenn die DB wirklich fertig ist, dann werde ich mal versuchen, meine erste Version mit der neuen DB zum Laufen zu bringen.
    Wenn das funktioniert, rede ich mal mit meiner Kollegin und bitte sie, meine erste Version statt der Uralt-Version zu benutzen. Das gibt mir dann in meinem neuen Programm die Möglichkeit, mit einem DS zu arbeiten und die DB zu vergessen. Ist zwar umständlich, aber eine gar nicht SO schlechte Idee...
    Your computer is running... You better go chase it! :P :D
    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 der generiert dann auch ein richtiges typisiertes Dataset davon.
    Das behalt ich mal im Hinterkopf ... Danke schön ;)

    Ich bin grad soweit, dass ich erstmal meinen Holzweg zu Ende geh und mit meiner nächsten Version sinnvoll auf typ. Datasets umsteig, weil mich das sonst einfach zu viel Zeit kostet, die ich im Moment einfach nicht habe und dann die DB wirklich steht ... Auch wenn ich dabei Gefahr laufe, ordentlich aufs Gesicht zu fallen ... Aber ich seh im Moment leider keine andere Möglichkeit, meine Leute brauchen das neue Programm und ich hab noch so ordentlich zu tun ...

    Aber danke trotzdem ;)
    Your computer is running... You better go chase it! :P :D
    Hallöchen Leute,
    ich melde mich mal zurück und berichte:

    Ich hab jetzt doch eeeendlich verstanden, wie ich das mit dem Dataset sinnvoll einbauen kann (ganz lieben Dank noch mal an @sonne75 ;) )

    Ich hab das jetzt mal so angefangen wie es mir @VB1963 in meinem anderen Thread mal geraten hat (DataSet oder Access-Datenbank)

    Eine wichtige Frage hab ich diesbezüglich aber:

    Bei den vom VS erstellten Datatables sind die IDs alle mit

    AutoIncrementSeed = -1
    AutoIncrementStep = -1
    MaxLength = -1

    angelegt ... Wenn ich die AutoIncrement-Sachen jetzt auf

    AutoIncrementSeed = 1
    AutoIncrementStep = 1

    ändere, fängt der Was-auch-immer dann nach einem .Fill des Datasets meinerseits wieder bei "1" an, neue Datensätze ins DS zu speichern??? Oder macht der dort mit zählen weiter, wo die letzte ID aufhört?!
    Weil wenn der da von vorn anfängt, geht mir da einiges kaputt ...

    Und das MaxLength = -1 heißt was??? Unbegrenzte Länge??? Weil das bräucht ich. Ich kann ja schlecht sagen: "Tja, bei 5000 Datensätzen ist Schicht im Schacht!"

    Wäre nochmals für eure Hilfe sehr dankbar ;)

    GlG Noyne
    Your computer is running... You better go chase it! :P :D
    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 inserten

    Wenn du von diesem TableAdapter-Theater mal die Nase voll hast , kannst du sie auch mal in DBExtensions reinstecken - das ist ein klein Framework, was diese blöden generierten TableAdapter üflüssig macht, und trotzdem richtig konfigurierte DataAdapter verfügbar hat.
    Wie ich verstanden habe, kann sie TableAdapter nicht nutzen, weil sie erst zur Laufzeit die Daten füllt (warum, weiß ich nicht, das muss sie ggf. nochmal erklären), da sagte ich, dass sie .Fill() nutzen kann. Stimmt es? Ich habe es hier nur aufgeschnappt...
    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).

    ErfinderDesRades schrieb:

    iwas "exotisches" machen muss

    ist gut!!! ICH würde lieber nur mit Dataset arbeiten, das kannste mir glauben. Aber meine Abnehmer meinen immer: "Wir wollen uuunbedingt eine Access-Datenbank, weil die ist viel schöner ..." Weißte, von tuten und blasen keine Ahnung, aber einen Blasmusikinstrumente-Chor leiten ... Kann ja so schwer nicht sein ...
    Und wenn ich dann mit neuen Ideen komm, heißt's immer: "Neeeee, das haben wir schon immer so gemacht!!" ... *seufz*

    Aber deine Links guck ich mir natürlich mal an!! Wäre doch gelacht, wenn ich das nicht hinkriege!!! ;)

    Die TableAdapter-Sache hab ich schon wieder über Bord geworfen ...

    Ich hatte ja noch die Idee, mir die Daten beim ersten Programmstart von der Access-DB in das Dataset zu ziehen und dann die Änderungen nur dort zu machen, also im Dataset. Ich wollte am Ende des Arbeitstages (für meine Abnehmer) oder beim Schließen des Programms gerne das Dataset in eine Access-DB umwandeln, wenn möglich. Ich hab da schon mal irgendwo was dazu gesehen. Kann das auch von dir gewesen sein, @ErfinderDesRades ?? Wenn ja, weiß ich grad ehrlich nimmer wo ...
    Your computer is running... You better go chase it! :P :D
    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 klappt das auch auf Anhieb - inklusive AutoWert-RoundTrip, aber bei Access musste da nachbessern, denn als DB kann die halt nicht ganz so viel wie SqlServer.

    mit "exotisch" meine ich jetzt deine Misch-Konstruktion, wo es scheinbar schon eine Produktiv-DB gibt, und du willst die iwie überarbeiten, aber ohne das bestehende Proggi zu ersetzen, und geht iwie nicht mit typDataset oder wasweißich - hab ich nicht verstanden.

    Noyne schrieb:

    beim Schließen des Programms gerne das Dataset in eine Access-DB umwandeln
    verstehe ich richtig: Beim Schließen willst du dann die ganze Access-DB weghauen und durch eine neue ersetzen? - na - das fände ich aber auch wieder exotisch - also so ist Datenbänkerei bestimmt auch nicht gedacht.

    ErfinderDesRades schrieb:

    willst du dann die ganze Access-DB weghauen und durch eine neue ersetzen?

    Ne ja, ich dachte da an was nummeriertes, aber die Idee:

    sonne75 schrieb:

    einfach die Werte wieder zurückspeichert? Mit .Update() und so?

    ist doch weit besser ... Also eher das was Sonnchen meint ;)

    ErfinderDesRades schrieb:

    wo es scheinbar schon eine Produktiv-DB gibt

    Produktiv-DB an sich nich, nein ...

    Also, ich beschreib's dir mal grob:

    Ich bin seit einem guten Jahr jetzt in meiner aktuellen Firma.
    Die Software, mit der meine aktuellen Abnehmer arbeiten, ist vor weit über 10 Jahren von einer Fremdfirma hergestellt worden und seitdem bei uns (bzw. meinen Abnehmer) im Gebrauch.
    Jetzt sind Anforderungen hinzugekommen, die die alte Software nicht mehr schafft.

    Meine erste Aufgabe war es, das Programm so wie es existiert 1:1 nachzubauen!! Das hab ich auch gemacht...

    Meine jetzige Aufgabe ist es, meine Nachbildung so zu erweitern, dass sie zu den Anforderungen passt!! Da bin ich gerade dran.
    Und da auch die Access-DB hinter der Original-Fremdsoftware angepasst werden muss, weil einige Tabellen-Felder vom Konzept nicht mehr passen oder ich ganz neue Tabellen brauche oder Felder gelöscht werden müssen/können, weil die keiner braucht oder was auch immer, habe ich die alte DB eben mit angepasst.

    Allerdings finde ich es wesentlich angenehmer mit Datasets zu arbeiten und wollte gern in meiner neuen Version auf ein Dataset umsteigen.
    Ich müsste mal bei meinem Abnehmer fragen, ob die Access-DB unbedingt nötig ist oder ob die auch eine XML-Datei als Datensicherungsquelle nutzen wollen/können ... Weil denen ist nur die Datensicherung wichtig (verständlicher Weise). Und das haben die halt immer mit "Datenbank rechtsklicken, kopieren, auf Stick einfügen" gemacht und davon sind se nur schwer abzubringen ;)

    Spannend wird es allerdings, wenn ich meine Anwendung multiuserfähig machen soll ... Aber das steht auf einem anderen Blatt und kommt erst in der nächsten Version ;)

    Was eignet sich denn für Multiuser-Anwendungen?? MySQL??
    Your computer is running... You better go chase it! :P :D
    So, ihr guten Leute ^^

    Ich steh grad wie die Kuh vorm Tor bei einer Sache, die wahrscheinlich total simpel ist:

    Ich würde gern im meinem Startform das gesamte Dataset füllen und dann formübergreifend drauf zugreifen wollen.
    Das (oder eins von einigen???) Helpers-Projekt hätt ich eingebunden, allerdings fehlt mir im Moment an sich schon mal diese Sache:

    "das gesamte Dataset füllen" ...
    Ich hab in meinem Programm immer DataAdapter gehabt, die ich mit

    VB.NET-Quellcode

    1. DataAdapter.Fill(DataTableName)
    gefüllt hab... Aber bei einem Dataset funktioniert das nicht 1:1 so, oder??

    Wäre nochmals für eure Hilfe dankbar ...
    Your computer is running... You better go chase it! :P :D
    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
    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 ;)