vb@rchiv
VB Classic
VB.NET
ADO.NET
VBA
C#
Blitzschnelles Erstellen von grafischen Diagrammen!  
 vb@rchiv Quick-Search: Suche startenErweiterte Suche starten   Impressum  | Datenschutz  | vb@rchiv CD Vol.6  | Shop Copyright ©2000-2025
 
zurück

 Sie sind aktuell nicht angemeldet.Funktionen: Einloggen  |  Neu registrieren  |  Suchen

VB.NET - Fortgeschrittene
Re: Probleme mit DataSet.HasChanges() 
Autor: Vinfler
Datum: 04.03.10 08:52

Vielen Dank zunächst für Deine Hilfe!

Es scheint als ob nun so langsam eine Lösung des Problems in Sicht ist. Allerdings habe ich noch einige Frage zu Deinen Lösungsvorschlägen. Ich bin leider noch ein ziemlicher Neuling in Sachen ADO.Net

Du empfiehlst zum DataBinding immer eine einzelne BindingSource pro Tabelle. Wenn ich Dich richtig verstanden haben, müsste die Umsetzung wie folgt erfolgen:

Private mGVPersonBindingSource As New BindingSource
 
 
mGVPersonBindingSource.DataSource = GVDataSet.Tables("Stammdaten")
 
Me.gesetzlicherVertreterVorsatzTextBox.DataBindings.Clear()
Me.gesetzlicherVertreterVorsatzTextBox.DataBindings.Add(New Binding("Text", _
  mGVPersonBindingSource, "Namensvorsatz", True))
Ist dies richtig so? Falls ja, würde ich das DataBinding in der gesamten SW umstellen. Offen ist jedoch für mich die Frage, wie ich nun genau die Methode EndCurrentEDit() des BindingContextes aufrufen soll. Ich stehe offen gestanden auf der Leitung

Es ist richtig, dass ich 3 DataSets mit jeweils anderen Stamm- und Kontodaten vorhalte. Dies war für mich die übersichtlichste Lösung um schon am DataSet zu erkennen, welche Daten es genau beinhaltet. Ist dieses Vorgehen aus Deiner Sicht ratsam oder sollte man lieber doch alle Tabellen in ein "großes" DataSet packen.

Allgemein erfolgt der Zugriff auf die Daten und somit das Befüllen der einzelnen DataTables über Tabellenwertfunktionen, welche auf dem SQL Server abgelegt sind. Damit ich auch nur die Daten zurückbekomme, die ich benötige, habe ich entsprechende Übergabeparameter definiert. SQL-Injection ist heutzutage sicherlich ein ernst zunehmenes Problem. Es ist daher sicherlich ratsam den Aufruf auf Command-Object umzustellen.

Was Dein Tipp für die Behandlung von Exceptions angeht, so schein ich wohl (von Anfang an) einiges missverstanden zu haben. Ich bin immer davon ausgegangen, dass ich eine Exception, wenn sie in einer untergeordneten Sub / Function auftritt, auf die beschriebene Art und Weise nach "oben" weiterleiten sollte. So dachte ich, kann ich genau rauskriegen, wo der Fehler genau aufgetreten ist. Deinem Ratschlag zu folge dürfte aber gerade dies bei meiner Vorgehensweise nicht funktionieren. Sollte ich daher auf den Try-Catch-Block verzichten oder einfach nur wie folgt vorgehen:

try
   ....
catch ex as Exception
   throw es
End try
Was das Neuanlegen von Daten angeht, so werde ich Deinen Tipp versuchen, umzusetzen. Aber erst eins nach dem Anderen

Was das Schreiben der Daten angeht, so habe ich dies bisher allerdings nur theoretisch wie folgt vorgesehen. Abfragen der Datasets, ob sich Änderungen an den Daten ergeben haben. Falls ja, Daten mittels SQL-Prozeduren in die Datenbank schreiben / aktualisieren oder löschen. Doch ob dies praktikabel und aus Sicht von .NET ratsam ist, da bin ich noch überfragt.
alle Nachrichten anzeigenGesamtübersicht  |  Zum Thema  |  Suchen

 ThemaViews  AutorDatum
Probleme mit DataSet.HasChanges()3.451Vinfler03.03.10 12:06
Re: Probleme mit DataSet.HasChanges()2.992ModeratorFZelle03.03.10 14:41
Re: Probleme mit DataSet.HasChanges()3.058Vinfler03.03.10 15:24
Re: Probleme mit DataSet.HasChanges()3.065Vinfler03.03.10 15:24
Re: Probleme mit DataSet.HasChanges()2.970ModeratorFZelle03.03.10 17:07
Re: Probleme mit DataSet.HasChanges()3.040Vinfler04.03.10 08:52
Re: Probleme mit DataSet.HasChanges()2.953ModeratorRalfE04.03.10 09:52
Re: Probleme mit DataSet.HasChanges()2.963ModeratorFZelle04.03.10 10:31
Re: Probleme mit DataSet.HasChanges()3.020Vinfler04.03.10 12:08
Re: Probleme mit DataSet.HasChanges()2.958ModeratorFZelle04.03.10 22:41

Sie sind nicht angemeldet!
Um auf diesen Beitrag zu antworten oder neue Beiträge schreiben zu können, müssen Sie sich zunächst anmelden.

Einloggen  |  Neu registrieren

Funktionen:  Zum Thema  |  GesamtübersichtSuchen 

nach obenzurück
 
   

Copyright ©2000-2025 vb@rchiv Dieter Otter
Alle Rechte vorbehalten.
Microsoft, Windows und Visual Basic sind entweder eingetragene Marken oder Marken der Microsoft Corporation in den USA und/oder anderen Ländern. Weitere auf dieser Homepage aufgeführten Produkt- und Firmennamen können geschützte Marken ihrer jeweiligen Inhaber sein.

Diese Seiten wurden optimiert für eine Bildschirmauflösung von mind. 1280x1024 Pixel