DataSets - Dies und Jenes

JackCimberly schrieb:

Dennoch finde ich keinen Datensatz in der Access-Datenbank und ebenso Daten abrufen im DataSet Designer.

Der erste Teil ist klar. Aber der zweite. Meinst Du damit, dass keine Daten im DataSet sind? In Access wird es erst sein, wenn Du einen Datenbank-Update-Befehl abschickst. Aber da bin ich raus. Mir reichen bisher meine tDS-Arbeiten. Im DataSet: Mach mal:

Wichtig!: Da darf kein try-catch-Block itgendwas abfangen!
Was kommt dabei raus?

Sorry, aber Postleitzahl sollte String sein. Wie soll sonst der 0er Bereich korrekt dargestellt werden. In einigen Ländern ist die Postleitzahl Alphanumerisch, in anderen gibt es Bindestriche.

Int kennt keine führende Nullen

JackCimberly schrieb:

Habe unter Datenquellen > KundenAnlegenDataSet > Rechtsklick auf KUNDEN "Datenvorschau" und in der Access-Datenbank nachgeschaut = kein Datensatz wurde hinzugefügt.
[---]
Ich bekomme jedes Mal die Meldung: "Alles bestens. Neue Row ist im tDS".
Von der obigen MessageBox.

Naja - wenn die Row im tDS ist - was immer das sein mag - so ist sie im tDS.
Da kannst du viel in der Datenbank gugge - die Datenbank ist ja nicht das tDS.

Datensätze im Dataset sieht man zur Laufzeit, wenn man zB ein daran gebundenes DGV auffm Form hat.

"Daten ablegen" ist nicht die richtige Vorstellung.
In meiner Welt tut man Daten in einer Datei ablegen, oder in einer DB (was letztendlich auch eine Datei ist).
Da liegen sie dann, auch nachdem das Proggi beendet wurde.

Ein tDS ist nur ein Objekt im Speicher zur Laufzeit, wie ein Integer, oder eine List(Of String).
Nur halt viel komplizierter aufgebaut, nämlich ebenso kompliziert wie die Datenbank, aus der das tDS befüllt wird (und in die das tDS seine Daten auch zurückspeichern kann).

@MrTrebron: Ja, da hast Du recht. Eine PLZ ist in nem String besser aufgehoben.
@JackCimberly: Entweder Du schaust mithilfe des Debuggers nach oder Du hast testweise z.B. ein DGV, welches an die KundenDataTable gebunden ist. Sobald in der DataTable sich was ändert, wird das im angebundenen DGV angezeigt.

VaporiZed schrieb:

In Access wird es erst sein, wenn Du einen Datenbank-Update-Befehl abschickst.

Natürlich muss man die tDS-Daten abspeichern, wenn man sie weiternutzen möchte. Man kann Access nehmen, das ganze in ne XML-Datei hauen oder sonstewie persistieren. Da macht das tDS keine Vorgaben. Es ist auch nicht seine (primäre) Aufgabe. Es leistet aber Hilfe. Für welchen Weg man sich auch entscheidet.
Als Beispiel:
Speichern in eine XML-Datei: DeinTds.WriteXML(Dateipfad)
Laden: DeinTds.ReadXML(Dateipfad)

JackCimberly schrieb:

Wie bekomme ich die Daten sofort und dauerhaft in die eingebundene Access-Datenbank?

Sofort und dauerhaft ist möglich, ist aber keine gute Option. Besser ist doch -wie etwa bei einem Word-Dokument - dass es einen Speichern-Button gibt, und gespeichert wird die Gesamtheit der Daten in dem Zustand, den der User fürs Speichern geeignet findet.
Ohne DB ist das wie gesagt kinderleicht: DAtaset.ReadXml/WriteXml()
Bei Mit Db sind DataAdapter dafür zuständig, das Dataset aus der Db zu befüllen und Neuigkeiten rückzuspeichern.
Dassis deutlich aufwändiger und erfordert einiges mehr an Kenntnissen.
Ich rate immer von Db ab.
Man kann vollständige Anwendungen ohne Db ausprogrammieren, und wenn am Ende tatsächlich eine Db-Unterstützung unverzichtbar ist, kann man sie auch nachträglich noch hinterlegen - das ist kein Mehr-Aufwand, weil das tDS wird ja weiter-genutzt.
Die Entwicklung ist sogar deutlich weniger Aufwand, denn wenn das Datenmodell anzupassen ist, hat man mit einer Db im Backend viel mehr Umstand, als wenn man nur das tDS umfrickeln muss.

Also ich zumindest verstehe es nicht. Was für Ordner, was für Dateien? Es gibt nur eine Datei.
Wenn Du Fahrzeuge, Kennzeichen, Kunden, Geschlechterangaben und ggf. noch viel mehr hast - und die sind ja bei Dir in DataTables gepackt (so, wie es sich gehört) - was für Ordner und Dateien brauchst Du dann? Jene Daten, die im tDS sind - und das können sehr viele sein - werden mit DeinTds.WriteXML(Dateipfad) in eine einzige Datei geschrieben. Und den Gegenbefehl führe ich immer nach Programmstart aus, sodass ich alle Daten mit einem Wisch wieder in meinen DGVs und anderen CEs habe. Auf jeden Fall verfügbar. Die XML-Datei ist im Extremfall (wie bei mir) immer nur am Programmanfang und am Programmende von Belang. Beim Laden und Speichern also. Sonst nie. Ist ja alles im tDS. Also im RAM/Arbeitsspeicher.
Ich geb's zu, ich arbeite mit vergleichsweise kleinen Programmen. Aber ich hab bisher immer nur ein einziges tDS pro Programm gebraucht. Es wird zwar immer von Formular zu Formular weitergereicht, damit man überall die selben (nicht die gleichen!) Daten hat, aber das ist ne andere Geschichte. Da will ich EdRs Highlanderprinzip nicht vorgreifen.

Schwierig erst beim Schließen zu speichern. Wenn dein Programm abbricht, der Rechner abstürzt und und und sind die Änderungen weg.
Du solltest schon gezielt zwischendurch speichern.

Nur mal eine Frage am Rande, soll die Anwendung von mehreren Benutzern gleichzeitig genutzt werden?

Backgroundworker ist veralteter umständlicher fehleranfälliger untypisierter Müll.

Nimm einfach einen Timer.

Und mach das als allerletztes.
Wenn sonst alles fertig ist, ist immer noch Zeit dafür.

Sonst tickert dir die ganze Entwicklungszeit über bei jedem Testlauf immer der Timer (oder gar der BGW) da zwischen drin rum.

Wie wäre es wenn ein Datensatz neu dazugekommen oder verändert wurde diese zu schreiben?
Grundsätzlich, würde man mit einer richtigen Datenbank arbeiten, schreibt man Änderungen direkt in die Datenbank.

MrTrebron schrieb:

Datenbank arbeiten, schreibt man Änderungen direkt in die Datenbank.

Das ist auch nur begrenzt so... Gibt ausnahmen...
Häufiges Beispiel:
Preisupdate... Dort führe ich erst alle Berechnungen durch und gebe sie als EINE Transaktion an die Datenbank, damit es nicht zu so Dingen kommen kann, wie ein Error der die Preisanpassung IRGENDWO abbricht.

Prinzipiell schreibt man immer zusammenhängende Transaktionen zurück in die Datenbank. Solange gibt es halt nen Lock auf die entsprechenden Daten.