Hallo

für die Schule mache ich gerade ein Projekt für die Ag-Verteilung in der Schule. Wir arbeiten mit einer Access Datenbank und auf diese greifen wir mit SQL-Befehlen zu. Das heißt bei insert und Update Befehlen sind die Daten sofort überschrieben.

Aus dieser Sache ergibt sich auch mein Problem. Ich habe schon dieses Drivetool benutzt um entsprechene Datenbanken anzeigen zu lassen und diese kann ich dann auch so öffnen, das ich sie für mein Programm öffnen kann. Ich möchte gerne, dass ich die Datenbank auswähle und dann mit ihr normal arbeite ( zum Beispiel mit einer kopie der ausgewählten Datenbank) und dann erst zum Schluß über einen Speicherbefehl die vorher ausgewälte Datenbank mit der veränderten überschreibe oder unter neuem Name speichere.

Könnt ihr mir dabei helfen?

mfg

kinghavi hat folgendes geschrieben:

Könnt ihr mir dabei helfen?

wobei denn ?
du hast doch die Vorgehensweise schon beschrieben, falls du irgendwo ein konkretes Problem hast, dann frag nach...

naja ich weiß nicht die Befehel um eine Datenbank zu kopieren und umzubennen, dann würde ich es wahrscheinlich hinbekomme. Könnt ihr mir die Befehle sagen?

Sowas ist zwar machbar, aber ich sehe den Sinn noch nicht. Wenn noch andere mit der Datenbank arbeiten, birgt Deine Idee mit einer Kopie zu arbeiten große Probleme beim Aktualisieren.
Erkläre doch mal den Sinn des Ganzen. Vielleicht gibt es einen besseren Ansatz.

mmh, kannst du nicht einfach die Access-Datei kopieren ?

Hi,

azubi_20 hat folgendes geschrieben:

mmh, kannst du nicht einfach die Access-Datei kopieren ?

doch kann er, er weis nur nicht, dass der CopyFile(pchar('Quelldatei'), pchar('Zieldatei'), false) dafür verwenden kann. Bzw. wenn er bestehende Dateien nicht überschreiben will CopyFile(pchar('Quelldatei'), pchar('Zieldatei'), true).

Aber die Warnung von jasocul ist absolut ernst zu nehmen und wir würden gerne helfen eine bessere Lösung zu finden.

Gruß
Klabautermann

Servus

Also es passiert ja einfach mal das man beim arbeiten mit der Datenbank fehler macht etc. Da wir SQL Befehele benutzen sind die unwiederrufbar und das wollte ich ändern, durch laden und speichern der Tabelle. ich mach das mal an einem Beispiel deutlich:

gearbeitet wird mit Tablle A, diese wird geladen nun wird davon eine Tabelle erstellt A2 die eine Kopie von A ist.

Mit A2 wird dann im Programm gearbeitet etc. und zum Ende hin speichert man diese wieder, in dem man A2 kopiert in A umbenennt und das ehemalige A löscht. Wenn man nicht speichert verfällt A2 und man kann das ehemalige A wieder laden.

hoffe das war verständlich!

grüße

Sobald Du mit mehreren an einer Datenbank arbeitest, wird das sehr Aufwändig. Du musste bei allen Änderungen in der Kopie prüfen, ob nicht schon der Original-Datensatz sich inzwischen geändert hat. Ähnliche Probleme mit Löschen und Erfassen.

Der Wille, hier einen Sicherungsmechanismus einzubauen, ist gut. Aber Access liefert dafür schon etwas (hoffe ich). Das nennt sich Transaktions-Kontrolle. Du kannst damit Änderungen auf dem Original durchführen, die zunächst nur für Dich sichtbar werden. Erst wenn die Transaktion abgeschlossen wird, werden die Veränderungen auch tatsächlich für alle sichtbar eingetragen.

Die notwendigen Stichwörter für die weitere Arbeit:
- Transaction / StartTransaction (Der Anwendung muss natürlich mitgeteilt, dass Sie transaktionsgebunden ist)
- Commit (Überträgt die Änderungen)
- Rollback (Macht die Änderungen Rückgängig)

ich fürchte das hilft mir nicht sehr, da die komplette umwandlung von delphi zuaccess unser lehrer macht und ich da null plan von habe und da nicht durchsteige. an der Datenbank werden aber nicht mehrere Leute gleichzeitg arbeiten, deswegen würde es auch so gehen!

das kopieren der Dateien klappt so weit, wie kann ich dateien löschen?

Dafür ist DeleteFile zuständig.

Access ist Transaction fähig? Hätte ich ihm gar nicht zugetraut.

klappt alles, danke schön!

Klabautermann hat folgendes geschrieben:

Access ist Transaction fähig? Hätte ich ihm gar nicht zugetraut.

Sachen gibt's ... die glaubt man fast nicht

Imho ist Access alles andere als transaktionsfähig. ADO ist transaktionsfähig, ebenso die BDE. Die puffert einfach alles, bis man 'commited' und bläst dann den Schmonz gebündelt in Richtung DB, sofern die DB so eine Krücke wie Paradox oder Access ist. Bei richtigen DBMS wird ein 'Start Transaction', 'Commit' bzw. 'Rollback' einfach durchgereicht.

Access ist ja keine zentrale Instanz, die eine Transaktionskontrolle durchführen könnte. Access ist ein Dateiformat, auf dem voneinander ziemlich unabhängige Treiber auf den Clients zugreifen und nur über eine kleine Datei (LDB?) miteinander 'kommunizieren'. Und auch das nur auf Record-Ebene. Soweit ich das beurteilen kann.

Nun, auch egal, denn was ihr meint, ist keine Transaktion, sondern ein eher Reconcile. Dabei müsste man mit einer Mittelschicht arbeiten, die simultanes Arbeiten an ein und dem selben (logischen) Datensatz steuert. Diese Mittelschicht kann ein waschechter Appserver sein, oder man bastelt sich (so wie natives Access) im Client eine Ebene, die das implementiert.

Dafür gibt es verschiedene Ansätze:
- der Einfachste ist, das gar nicht zuzulassen. Der Client, der einen Datensatz anfordert, schaut in einer Locktabelle nach, ob der schon von jemand anderem benutzt wird. Wenn nicht, schreibt er die Datensatznummer in die Locktabelle und zieht die Daten. Nach der Beendigung der Bearbeitung wird der Eintrag wieder aus der Locktabelle gelöscht. Nachteil: Schmiert die Anwendung ab, bleibt der Datensatz gesperrt. Ich glaube sogar, das Access Recordlocking (über ADO) beherrscht, sodaß man hier nichts extra programmieren müsste.

- Konfliktauflösung bei simultaner Bearbeitung. Wenn mehrere Clients an ein und demselben Datensatz arbeiten, tun sie das ja meist an unterschiedlichen Stellen: Der Eine ändert vielleicht die Adresse, der nächste die Bankverbindung etc. Eine klug programmierte Konfliktauflösung vermischt die Änderungen und meckert nur, wenn zwei Clients ein und das selbe Feld geändert haben. Hier gibt es auch wieder unterschiedliche Strategien:
-- Der Erste gewinnt. Subsequente Änderungen innerhalb der Änderungssession werden ignoriert.
-- Der Letzte gewinnt. Subsequente Änderungen werden in die DB geschrieben.
-- Man fragt den Anwender, was zu tun ist. (Imho die eleganteste Lösung).

Das ein Lehrer 'so mal eben' soetwas mit seinen Schülern programmieren will... Alle Achtung.