Primärschlüssel in DGV neu vergeben/ sortieren

  • VB.NET

Es gibt 21 Antworten in diesem Thema. Der letzte Beitrag () ist von klyer.

    Primärschlüssel in DGV neu vergeben/ sortieren

    Hallo Leute,

    ich habe ein kleines Problem mit meinem DGV welches aus einer accdb also Access DB Daten einliest.
    Folgendes Problem: Die Tabelle ist ein Adressbuch mit mehreren Spalten wobei jeder neue Kontakt immer eine neue ID (Primärschlüssel) bekommt. Über die Zeit werden aber auch Kontakte gelöscht und damit fehlen ein paar "ID's"
    z.B.

    1
    2
    4
    7
    8
    10
    ...

    Wenn ich nun einen Kontakt bearbeiten möchte so wird immer ein "falscher" Kontakt aufgerufen, weil ja die Reihenfolge nicht mehr stimmt bzw. die Zugewiesene ID nicht mehr vorhanden ist.
    z.B. wenn ich die ID 4 aufrufen will, gibt er mir den Kontakt mit der ID 8 aus...

    Normalerweise löse ich das so:

    VB.NET-Quellcode

    1. Dim i As Integer = DataGridView1.CurrentRow.Index
    3. ... DataGridView1.Rows(i).Cells(0).Value ' Damit ruf ich mein Formular zum bearbeiten auf



    Wie kann ich nun die Reihenfolge der ID's / Primärschlüssel neu sortieren bzw. vergeben lassen?

    Dann hast Du totalen Mist im Datenmodell. ;)
    Die Row die Du auswählst sollte normalerweise in der Bindingsource sein. Anderenfalls hast Du einen Fehler impliziert.

    Versuchst Du zu Filtern oder wählst Du den Datensatz direkt über das View?

    Naja, die DB/ Tabelle kommt aus einer Access...und wird einfach in das DGV ausgegeben. Wahrscheinlich ist einfach das Problem, dass ich es nicht hin bekomme, die richtige angewählte Zeile zu selektieren....
    Der Aufbau und der Code der DB und des DGV stammt überwiegend aus einem von den VB-Bücher (VB2010 Kochbuch)

    Also nachfolgend der Salat: :)

    VB.NET-Quellcode

    1. Private conn As New OleDbConnection("Provider=Microsoft.ACE.OLEDB.12.0; Data Source = Database.accdb;")
    2. Dim da As OleDbDataAdapter = Nothing
    3. Private dt As DataTable = Nothing
    4. Private dv As DataView = Nothing
    5. Private drv As DataRowView = Nothing
    7. Protected Overrides Sub OnLoad(ByVal e As System.EventArgs)
    8. da = New OleDbDataAdapter("SELECT ID, Anrede, Vorname, Nachname, Firma, Straße_Nr, PLZ, Ort, ... FROM Kontakt", conn)
    9. Dim cb As New OleDbCommandBuilder(da)
    11. dt = New DataTable("Kontakt")
    12. conn.Open()
    13. da.Fill(dt)
    14. conn.Close()
    15. Dim bs As New BindingSource()
    16. dv = New DataView(dt)
    17. bs.DataSource = dv
    18. DataGridView1.DataSource = bs
    19. DataGridView1.DataSource = dv
    20. MyBase.OnLoad(e)
    22. End Sub



    Damit wird ja die DB geladen und in das DGV gegeben. Nachfolgend nun, wie es in das "Bearbeiten"-Formular übergeben wird:

    VB.NET-Quellcode

    1. Private Sub btnEdit_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnEdit.Click, DataGridView1.CellDoubleClick
    2. Dim i As Integer = DataGridView1.CurrentRow.Index
    3. Try
    4. drv = dv(CInt(DataGridView1.Rows(i).Cells(0).Value))
    5. Dim f2 As New DBNeuBearbeiten()
    6. f2.editGast(drv)
    7. f2.Dispose()
    8. Catch ex As Exception
    9. MsgBox(ex.Message)
    10. End Try
    11. End Sub



    Option Strict On natürlich.

    Sorry...aber der Code lässt sich gerade nicht anders Formatieren.

    [(so, und nun tu ich mir diesen Post in meine Favoriten, dassich ihn jedem um die Ohren hauen kann, der unanständig gelayouteten Code postet)] Danke! :)

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „klyer“ ()

    Vielen Dank "StormySunshine" für dein Code.

    Was wahrscheinlich eher der Fehler ist, dass ich vl. den falschen Code verwende, um auf einen Eintrag im DGV zuzugreifen. Denn das Löschen funktioniert ja einwandfrei. Also wenn jm. einen Tip hat, wie ich den richtigen Eintrag selektiere dann wäre ich sehr dankbar denn die DB ist an sich eig. schon im fertigen Status.

    Eine weitere Frage habe ich aber noch: Was für ein System Datenbank ist für ein Adressbuch bzw. sehr viele Kontakte geeignet? (Es geht um das Händeln von ca. 1000 - 5000 Einträgen) - ist Access da noch geeignet?

    Für bis wasweißich - 50000 Datensätze braucht man ühaupt keine Datenbank.
    Auch sollteman überhaupt nie eine DB-Anwendung mit einer Datenbank entwickeln - immer erstmal DB-Programmierung ohne Datenbank. DB hinterlegen ist eine annere Baustelle, die besser erst in Angriff genommen wird, wenn alles bereits läuft, und auch dann nur, wenn sich tatsächliche Probleme auch zeigen.
    Das gilt sogar für erfahrene Coder, und natürlich für Einsteiger erst recht.

    Eine Frage habe ich noch für zwichendurch:

    Eine DB über XML laufen zu lassen erscheint mir sehr komfortabel und hat bestimmt auch viele Vorteile - nur wo liegen dann die Vorteile einer richtige DB (Access DB)?

    @ErfinderDesRades
    Dein Tutorial zu "DatasetOnly: DB-Programmierung ohne Datenbank" finde ich sehr gut nur hast du auch ein Beispiel oder eine Website in welcher diese Möglichkeit mit nur einer DB (Tabelle) mit Löschen, Hinzufügen und Bearbeiten beschrieben wird? Sozusagen ein bisschen Einsteigerfreundlicher...

    klyer schrieb:

    ein Beispiel oder eine Website in welcher diese Möglichkeit mit nur einer DB (Tabelle) mit Löschen, Hinzufügen und Bearbeiten beschrieben wird?
    Most Primitive - Update ist doch ein Dataset mit nur einer Tabelle - probiert ihr die beiliegenden Sources eigentlich ühaupt nicht aus?

    Und achte auf genaue Begriffe: "diese Möglichkeit mit nur einer DB (Tabelle)" - dassis so falsch, dasses kaum noch verständlich ist.
    Eine DB ist keine Tabelle - bei "DB (Tabelle)" ist eiglich beim besten Willen nicht sicher verständlich, was du meinst, zumal von DBs ja garnet die Rede ist, sondern immer nur von Datasets.

    Eine DB ist keine Tabelle, ein Dataset ist keine DB. Sowohl DBs als auch Datasets enthalten Tabellen, bei Dataset heißen diese Tabellen korrekterweise DataTables, und bei typisiertem Dataset nenne ich sie typDataTable.

    wo liegen dann die Vorteile einer richtige DB (Access DB)?
    jetzt redest du wirklich vonner DB, ja? ;)
    In einen Netzwerk oder auch im Internet ist DatasetOnly natürlich abgehängt.
    Eine DB bietet MultiUser-Zugriff, und kann gigantische Datenmengen performant verwalten, die man nicht mehr komplett einfach in den Speicher laden kann.

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „ErfinderDesRades“ ()

    Vielen Dank für die umfangreiche Erklärung. Mir ist bewusst, dass eine DB keine Tabelle ist ich verwende ja selber eine DB mit mehreren Tabellen.
    Da mein Projekt schon mit einer Access DB im aktiven Betrieb läuft, werde ich eher nicht zu einer XML basierten "DB" greifen dennoch könnte sie für andere Aufgaben sehr nützlich sein.
    Heute Abend werde ich mir das Problem, welches ich mit dem Aufrufen eines Eintrages habe, noch einmal anschauen und dann berichten.

    was ich in deim Code sehe ist, dass du BindingSources, DataViews, DataTables zur Laufzeit erstellst - dassis einfach Crap

    Um Daten vernünftig zu verarbeiten muß man den Kram im Designer einrichten, und beim Datenabruf das typisierte Dataset befüllen - nicht flugs neue Datasets oder DataTables erstellen. Weil die neu erstellten Dinger sind untypisiert, und haben natürlich nicht die Bindings, und das mitte Bindings kann recht komplex werden.

    Also schmeiß dein Kochbuch in die Tonne, und fang dein Projekt neu und DatasetOnly an. Willst du mit der bestehenden DB weitermachen, dann musste jetzt designergestütztes Databinding erlernen und gleichzeitig den DB-Zugriff, wie er designergestütztes Databinding ühaupt unterstützt - der Kochbuch-Code ist dafür total ungeeignet.
    Und nur wenn du beides gleichzeitig richtig machst, kriegst du ühaupt was sinnvolles zu sehen - ansonsten tappst du immer schön im Dunkel.
    Daher ist besser sich in eins nachm anneren einzuarbeiten, und Databinding kommt vor DB-Zugriff.

    Aber ich hab auchn Tut, was beides gleichzeitig vorzeigt, so leidlich: "Datenbank in 10 Minuten" auf Movie-Tuts.
    Aber empfehlen kannichdas nicht wirklich - nur für Dickköppe, die sich geistig nicht von "Datenbank! Datenbank!" lösen können.

    Hihi - annerer Vorschlag: Ich könnte deine DB in paar minuten in ein Xml-Dokument umwandeln, sogar gleich mit einem Projekt, wasses ordentlich lädt und speichert.

    Das ist doch blöd! Da hat man eine einfache Frage zu Datenbanken gestellt und schon wird das ganze über den Haufen geschmissen. Als Anfänger fand ich Access sehr einfach (man hat sich auch in Stundenlanger Arbeit reingefuchst) eben weil es in den Büchern (VB2010 Kochbuch, VB2010 Für Einsteiger und Fortgeschrittene, VB2012 Kochbuch, ...) rel. gut beschrieben wurde. Es ist halt die Frage: Wer hat Recht? Ihr könnt die Bücher der Autoren gern über den Haufen schmeißen, nur wissen diese vl. eher was sie Tun?!

    Zu meinem Projekt um es mal anzuschneiden und ihr auch wisst worauf ich hinaus will:
    Es ist ein Hotel Rechnungshelfer, welcher in wirklich einfacher Art eine Rechnung mittels Word generiert. Alle Gäste werden vorher in eine DB (Access) gespeichert um sie später evtl. wieder abzurufen. Ebenso funktioniert eine "Statistik", in welche alle Kosten eingetragen werden.
    Das beste am ganzen ist, dass es aktiv verwendet wird - Klar, sonst hätte ich ja auch keine Lust zu programmieren - Denn es gibt nichts besseres für einen Programmierer (Anfänger) als wenn sein Programm auch tatsächlich jeden Tag verwendet wird - sonst kann man seinen Job ja in die Tonne kloppen!

    Jetzt werde ich mir das ganze mit dem XML noch einmal durchlesen und evtl. auch umsetzen - Dank an euch!

    klyer schrieb:

    Das ist doch blöd! Da hat man eine einfache Frage zu Datenbanken gestellt und schon wird das ganze über den Haufen geschmissen.
    klar ist das frustrierend. Aber annererseits ist das nichts wirklich ungewöhnliches. Inne Software-Entwicklung werden auch mal voll entwickelte Prototypen mit was weiß ich wievielen Mannstunden schlicht in die Tonne gekloppt, weil sich halt ein besseres Konzept anfand. Das sind normale Entwicklungskosten.

    Es ist halt die Frage: Wer hat Recht? Ihr könnt die Bücher der Autoren gern über den Haufen schmeißen, nur wissen diese vl. eher was sie Tun?!
    Oder auch nicht.
    Probiers halt aus. Oder auch nicht, und vertrau dem Author, der ein Buch über Datenverarbeitung schreibt, ohne typisiertes Dataset zu erwähnen.
    Kannst dir auch mal paar Videos von MS angugge: Forms over Data Videos - nicht dass du denkst, ich hätte mir die typDataset-Geschichte selbst ausgedacht ;)

    Selbstausgedacht ist die Entdeckung, dass typDataset auch ganz ohne DB funktioniert, und bis wasweißich 50MB Dateigröße sogar besser als mit DB.
    Und dass man den Lernstoff ausgezeichnet aufteilen kann.
    DB ohne typDataset - taugt nix :thumbdown:
    typDataset ohne DB - kein Problem :D
    Daraus ergibt sich logisch die von mir propagierte Reihenfolge der Einarbeitung.

    Oder - wie bereits angeboten: Rück deine Anwendung rüber, und ich bastel das um auf Xml, inklusive grundlegender Datenverarbeitung.
    KundenDaten bitte rauswerfen und durch DummiDaten ersetzen.

    Allerdings, der Crossover nach Word könnte mir Probleme machen, weil ich hab nur ein sehr altes Word.
    Auch weißichnicht, ob deine WordLösung selbständig in die DB greift - sowas ist möglich, und das wäre natürlich ein entscheidendes Argument gegen DatasetOnly.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „ErfinderDesRades“ ()

Facebook
Telefonspende