Datagridview zeigt richtige Anzahl an Zeilen an, aber die Zellen bleiben leer. In der Bindingsource sind aber Daten vorhanden.

  • VB.NET

Es gibt 24 Antworten in diesem Thema. Der letzte Beitrag () ist von DianonForce.

    Datagridview zeigt richtige Anzahl an Zeilen an, aber die Zellen bleiben leer. In der Bindingsource sind aber Daten vorhanden.

    Moin Com,

    meine für mich merkwürdigen Phenomäne höhren nicht auf.

    Ich Lade aus meinem Form 'Main' für die Bearbeitung eines Datensatzes, dass Form 'Ansicht' und übergebe dem Form 'Ansicht' einen Datensatz aus 'tbl_beleg_kopf' .

    VB.NET-Quellcode

    1. If Tbl_beleg_kopfBindingSource.EditCurrent(Of Ansicht) = DialogResult.OK Then
    2. End If


    'tbl_beleg_kop' ist parent von 'tbl_beleg_pos' welche wiederum parent von 'tbl_beleg_pos_unt' ist.


    Im Form 'Ansicht' habe ich einige TextBoxen und 2 Datagridviews.
    Die Textboxen sind an 'tbl_beleg_kopf' gebunden.
    Das erste Datagridview ist an die Relation 'tbl_beleg_kopf -> tbl_beleg_pos' der BindingSource von 'tbl_beleg_kop' gebunden.
    Das zweite Datagridview ist an die Relation 'tbl_beleg_pos -> tbl_beleg_pos_unt' der Bindingsource 'tbl_beleg_pos' gebunden.

    Wenn das Form angezeigt wird, werden sowohl die Textboxen als auch das erste DGV komplett mit Inhalten angezeigt, das 2. DGV zeigt nur ein leers Grid mit der korrekten Anzahl an Rows an.
    Schließe ich das Form und öffne es erneut, sind auch die Daten im 2. DGV sichtbar.

    Ich kann beim ersten Öffnen des Forms eine Row im 2. DGV auswählen und wenn ich dann auch die current Reo der BS zugreife bekomme ich auch die korrekten Daten, es schein also rein ein Anzeigeproblem zu sein.

    Die DataTables für die DGV's lade ich im BS.change Event der BS für 'tbl_beleg_kopf'

    VB.NET-Quellcode

    1. Dim rwKdstamm = V_kdstammBindingSource.At(Of v_kdstammRow)
    2. If rwKdstamm.Null Then Return
    3. BusyDelay.SetCallback(Sub() rwKdstamm.FillChildTables(KisDataSet.tbl_adressen, KisDataSet.tbl_beleg_kopf))


    Ich nehme mal an, das die Oberfläche schneller läd als die Daten in den Datatables, das problem hab ich schon öfters gehabt, bisher konnte ich dies aber Designtechnisch umgehen, diesmal leider aber nicht.

    Ich mache sicher etwas aus Unwissenheit falsch. Wenn mir also wer mit dem Zaunpfahl einen Wink geben könnte :D .

    *Topic verschoben*

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Marcus Gräfe“ ()

    Ok, neuer Verusch, hab die Notwendigen Datensätze aus der DB in eine mdb exportiert und an das Dataset connected, da macht sich das echt bezahlt :D.

    Ich hoffe die läuft bei dir.

    PS: Eigendlich hatte ich erwartet, dass das Phenomän jetzt weg ist, ist ja normal so, das Testumgebungen immer funktionieren :D, aber Glück gehabt, es ist anscheinend reproduzierbat
    Dateien
    • Test.zip

      (4,1 MB, 85 mal heruntergeladen, zuletzt: )
    Im Anhang ein typDataset von mir.
    Kannst du vlt. ein neues typDataset erstellen, und von meim die Tabelle da reinkopieren, und abspeichern und anhängen?
    Dann kann man vlt. durch einen Vergleich herausbekommen, worans hapert mit VS>13.
    Dateien
    • ForExportDt.zip

      (1,65 kB, 72 mal heruntergeladen, zuletzt: )
    Ok, hab mal 2 erstellt, eins unter .net 4 und eins unter .net 4.5.1

    Hab gesehen deine DBEx sind alle unter .net 4 meine stehen auf .net 4.5.1. Bin nur beim grob googlen auf nen Post gestosen wo jemand auch das Prob hatte das er seine Datasets nicht mehr öffnen konnte, angeblich hat das geholfen, kann aber auch kompletter mist sein.
    Dateien
    • DS.zip

      (3,33 kB, 93 mal heruntergeladen, zuletzt: )
    Hm, wenn ich jetzt wüsste was ich an dem DS anders gemacht hab als an meinen, ausser das ich bei meinen die Tabellen aus dem Server-Explorer gezogen hab und bei den beiden jetzt einfach die DT aus deinem kopiert hab :/

    Edit: Ok, hab nochmal die DT und Relations aus meinem Projekt in ein neues DS kopiert, vielleicht geht das jetzt ja
    Was mir auch noch einfiel, die DS die ich aus der DT aus deinem Dataset erstellt habe, haben alle keine Relations vielleicht liegts daran, hab eins der beiden von gestern noch um ne Relation erweitert.
    Dateien
    • DataSetWithRelation.zip

      (1,66 kB, 70 mal heruntergeladen, zuletzt: )
    • TestDS.zip

      (19,45 kB, 72 mal heruntergeladen, zuletzt: )

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

    Kann alles eingelsen werden. Nur das db_serviceticket.xsd zickt rum - oder hatte ich noch eins vergessen?

    Ah - ich hab jetzt eine Lösung!
    Ich kann dein Projekt mit meim SolutionExplorer downgraden auf 2013 - dann werden die Datasetse scheints richtig erkannt.
    Wundert mich, weil mein SolutionExplorer fasst xsd-Files dabei garnet an.
    Seisdrum Problem solved.
    (Naja, fürs erste jedenfalls siehts so aus, wenn ich nichtn Denkfehler drinne hab)

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

    Hm, komisch, warum jetzt nur das eine noch zickt.

    Da fällt mir noch was zu ein. Jedes mal wenn ich aus dem Server-Exploerer nachträglich noch eine Tabele aus der Datenbank in das Dataset ziehe, legt mir Visual Studio 15 eine neuen ConnectionString in die Settings.
    Also Connection, Connection1, Connection 2, ... Sind aber alles ansich die selben Connections, ich lösch die dann immer aus den Settings raus, danach meckert immer VS das das Dataset nen Fehler hat, und die Connection1 z.B. nicht findet. Da sich das DS dann nicht mehr im VS öffnen lässt, bearbeite ich es mit Notepad++ und werf den Eintrag für die doppelte Connection wieder raus. Bei mir führt das zu keinen merklichen Problemen, aber vielleicht verhunds ich da was in den Datasets, was den import verhindert.

    Sorry, ist mir jetzt erst wieder eingefallen. Wie gesagt, mach ich schon ne ganze Zeit so und hat nie zu merkbaren Problemen bei mir geführt.
    geht um diesen Block hier am anfang der DS.xsd

    Quellcode

    1. <Connections>
    2. <Connection AppSettingsObjectName="MySettings" AppSettingsPropertyName="kisConnectionString" ConnectionStringObject="" IsAppSettingsProperty="true" Modifier="Assembly" Name="kisConnectionString (MySettings)" ParameterPrefix="@" PropertyReference="ApplicationSettings.Kalkulation.My.MySettings.GlobalReference.Default.kisConnectionString" Provider="MySql.Data.MySqlClient" />
    3. </Connections>
    So, habe den Bug jetzt fixen können.
    Naja, Workaround - tatsächlich weiss ich nicht, was da wirklich schief läuft.

    VB.NET-Quellcode

    1. Private Sub KalkulatinAnsicht_Load(sender As Object, e As EventArgs) Handles Me.Load
    2. Dim rwBelegKopf = bsBelegKopf.At(Of tbl_beleg_kopfRow)()
    3. If rwBelegKopf.Null Then Return
    4. rwBelegKopf.FillChildTables(KisDataSet.tbl_beleg_pos, KisDataSet.tbl_beleg_pos_unt)
    5. bsBelegPos_Unt.ResetBindings(True)
    6. End Sub
    BindingSource_CurrentChanged wird hierbei nicht mehr verwendet.
    Achtung: ich hab zumindest die BindingSources umbenannt (wie kannst du nur mit solche Namens-Krankheiten programmieren?)



    zum editierten Dataset: Jo, kann natürlich sein.
    Wundert mich allerdings, dasserda die Connection ins Dataset schreibt, wo du doch alle TableAdapter entfernst - oder?

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

    Danke! Es beruhigt mich, dass ich zumindest nix elementares übersehn habe.

    Du hast ja die 'kranken' Tabellen gesehen, ich weiß echt nicht was meinen Vorgänger geritten hat soviel Zeug in eine Tabelle zu packen. Jedenfalls wenn ich das dann aufs Form ziehe hab ich so viele Namen zu ändern - ich hab noch keine schnelle Methode gefunden, wie ich die Namen vieler Objekte auf einmal ändern kann und jedes einzel anklicken, dann in die Eigenschaften den Namen suchen und ändern ist echt ne Tortur - da hab ich irgendwann resigniert und VS einfach machen lassen :( Eine Tabelle mit allen Objekten, wo man einfach die Namenssplate durchgehen kann und recht zügig ändern kann wär was schönes.

    Ja, die TableAdapter werf ich gleich wieder raus, aber vermutlich wirft VS den Connectionstring nicht automatisch mit raus.

    PS: würde noch gerne was fragen, was nicht 100% hier rein passt, hat aber auch mit dem fill der Datatables zu tun. ich hab auf ein par Textboxen ein change Event sitzen, dass triggert natürlich gleich schon los, wen die Datasets befüllt werden, kann ich das verhindern, oder muß ich die Handler einfach erst nach dem Form Load adden?
    Ich muß den Thread nochmal wiederbeleben.

    Wenn ich eins der Felder die auch schon im 2. DGV angezeigt werden, mir ins Form ziehe (als Detailansicht), mekert VB beim öffnen des Forms.

    Ein Ausnahmefehler des Typs "System.ArgumentException" ist in System.Windows.Forms.dll aufgetreten.

    Zusätzliche Informationen: An die Eigenschaft oder Spalte pos_unt_artikel_id für die DataSource kann nicht gebunden werden.


    Das Gleiche hab ich ja schon mit den Feldern der 1. DGV gemacht, da gibts aber keine Probleme :/

    Wenn ich das Binding für die Textbox im Designer rauswerfe, und dann erst im Load Event des Forms, nach dem .FillChildTables, per hand mache, funktioniert es, aber da werd ich doch wahnsinnig das für jedes Control einzeln zu machen.

    VB.NET-Quellcode

    1. Dim rwBelegKopf = Tbl_beleg_kopfBindingSource.At(Of tbl_beleg_kopfRow)
    2. If rwBelegKopf.Null Then Return
    3. rwBelegKopf.FillChildTables(KisDataSet.tbl_beleg_pos, KisDataSet.tbl_beleg_pos_unt)
    4. Tbl_beleg_pos_untBindingSource.ResetBindings(True)
    5. Pos_unt_artikel_idTextBox.DataBindings.Add("Text", Tbl_beleg_pos_untBindingSource, "Pos_unt_artikel_id")


    Das ganze scheint ein Problem von .EditCurrent zu sein, wenn ich das Form direkt aufrufe hab ich das Problem nicht. Oder ich umgehe es irgendwie.

    Ich häng das veräderte Beispiel nochmal an
    Dateien
    • Test.zip

      (4,1 MB, 89 mal heruntergeladen, zuletzt: )

    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „DianonForce“ ()

    @DianonForce Was muss ich tun, um Deinen Effekt zu reproduzieren?
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!