7
Access Problem Autowert und insert Funktion
Guten Morgen zusammen,
ich hab folgendes Problem:
Access Tabelle im Backend mit Autowert als Primärschlüssel.
Zur Bearbeitung wird ein Teil der Tabelle in eine lokale kopiert.
Also 1. lokale löschen, dann via insert aus dem backend in das frontend kopiert.
Mit Anwendungsende werden die Daten wieder zurück geschoben, also "involvierter" Teil des backends löschen
und wieder mit insert die lokale ins backend kopiert.
Beide Tabellen haben die selbe Struktur.
Bisher klappte das auch gut, da die insert Funktion den Autowert nicht angefasst hat sondern
nur die eigentlichen Daten kopiert hat und der jeweiligen Tabelle die Steuerung des Autowerts
überlassen hat.
Heute morgen schmiert mir das frontend ab mit der Fehlermeldung ... doppelter Index ... usw. ihr wisst schon.
Und tatsächlich gehe ich in das backend öffne die Tabelle direkt und versuche einen neuen Datensatz einzugeben
wird als nächster Autowert eine Zahl vergeben die längst existiert.
Reparatur durchgeführt ... keine Besserung.
andere Tabelle mit selber Struktur angelegt, Daten kopiert, alte gelöscht, neue umbenannt, jetzt geht das wieder.
Liegt das an der insert Funktion ?
Sollte ich lieber mit while () wend arbeiten und über .addnew und .update die Daten einfügen ?
Danke für Hilfe.
ich hab folgendes Problem:
Access Tabelle im Backend mit Autowert als Primärschlüssel.
Zur Bearbeitung wird ein Teil der Tabelle in eine lokale kopiert.
Also 1. lokale löschen, dann via insert aus dem backend in das frontend kopiert.
Mit Anwendungsende werden die Daten wieder zurück geschoben, also "involvierter" Teil des backends löschen
und wieder mit insert die lokale ins backend kopiert.
Beide Tabellen haben die selbe Struktur.
Bisher klappte das auch gut, da die insert Funktion den Autowert nicht angefasst hat sondern
nur die eigentlichen Daten kopiert hat und der jeweiligen Tabelle die Steuerung des Autowerts
überlassen hat.
Heute morgen schmiert mir das frontend ab mit der Fehlermeldung ... doppelter Index ... usw. ihr wisst schon.
Und tatsächlich gehe ich in das backend öffne die Tabelle direkt und versuche einen neuen Datensatz einzugeben
wird als nächster Autowert eine Zahl vergeben die längst existiert.
Reparatur durchgeführt ... keine Besserung.
andere Tabelle mit selber Struktur angelegt, Daten kopiert, alte gelöscht, neue umbenannt, jetzt geht das wieder.
Liegt das an der insert Funktion ?
Sollte ich lieber mit while () wend arbeiten und über .addnew und .update die Daten einfügen ?
Danke für Hilfe.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 97321
Url: https://administrator.de/contentid/97321
Ausgedruckt am: 23.11.2024 um 04:11 Uhr
7 Kommentare
Neuester Kommentar
Bei solchen Aktionen muss man wissen, was ein Autowert bedeutet.
Beim Kopieren der Daten von der Haupt-DB müssen die Autowerte zwecks späterem Abgleich kopiert werden. Die Temp-DB darf dann bekanntlich keine Autowerte, sonden normale Longwerte speichern.
Das geht ja bekanntlich bei Ihnen.
Jetzt, nachdem die Daten bearbeitet sind, wird das Ganze zurückgeschrieben. Aber nicht mit INSERT INTO..., sondern mit UPDATE TABLE SET X=, y=... WHER ID=ID.
Ein versehentliches Anfügen von Daten an die Haupt-DB kann nicht funktionieren.
Auch wenn die Daten vorher gelöscht würden, eine Autowert wird niemals wieder gleich vergeben. Nach dem Zurückschreiben muss per Abfrage sichergestellt werden, dass die Daten wirklich vorhanden sind in der Hauft-DB, anschliessend muss die Temp-Tabelle geleert werden.
Zu etwas anderem: Warum verknüpfen Sie die Tabelle nicht einfach und greifen darau zu. Ist die Haupt-DB nicht verfügbaer, muss offline gearbeitet werden?
Wenn die Haupt-DB verfügbar ist, wäre der richtige Schritt: Eine verknüpfte Tabelle anlegen in der Temp-DB. Dann ist schon alles erledigt.
Beim Kopieren der Daten von der Haupt-DB müssen die Autowerte zwecks späterem Abgleich kopiert werden. Die Temp-DB darf dann bekanntlich keine Autowerte, sonden normale Longwerte speichern.
Das geht ja bekanntlich bei Ihnen.
Jetzt, nachdem die Daten bearbeitet sind, wird das Ganze zurückgeschrieben. Aber nicht mit INSERT INTO..., sondern mit UPDATE TABLE SET X=, y=... WHER ID=ID.
Ein versehentliches Anfügen von Daten an die Haupt-DB kann nicht funktionieren.
Auch wenn die Daten vorher gelöscht würden, eine Autowert wird niemals wieder gleich vergeben. Nach dem Zurückschreiben muss per Abfrage sichergestellt werden, dass die Daten wirklich vorhanden sind in der Hauft-DB, anschliessend muss die Temp-Tabelle geleert werden.
Zu etwas anderem: Warum verknüpfen Sie die Tabelle nicht einfach und greifen darau zu. Ist die Haupt-DB nicht verfügbaer, muss offline gearbeitet werden?
Wenn die Haupt-DB verfügbar ist, wäre der richtige Schritt: Eine verknüpfte Tabelle anlegen in der Temp-DB. Dann ist schon alles erledigt.
ok, das mit dem update table wird ich umsetzen,
und zu "zu etwas anderem", die Idee zur lokalen Variante des backends ist enstanden aus performance Gründen. Arbeite ich mit der verknüpften Variante des backends ist das sehr langsam, mit der lokalen Variante funktionierts.
Danke für den Tipp, probier ich gleich
und zu "zu etwas anderem", die Idee zur lokalen Variante des backends ist enstanden aus performance Gründen. Arbeite ich mit der verknüpften Variante des backends ist das sehr langsam, mit der lokalen Variante funktionierts.
Danke für den Tipp, probier ich gleich
mmmh, jetzt klappt das Ganze recht gut, wenn es da nicht noch die Möglichkeit gäbe in dem lokalen frontend auch neue Datensätze zu erstellen ...
d.h. lokal brauch ich doch einen Autowert und mit update table werden nur vorhandene Positionen angefasst aber nicht die neu angelegten in der lokalen db.
Ich mach glaube doch lieber while () wend und .addnew
d.h. lokal brauch ich doch einen Autowert und mit update table werden nur vorhandene Positionen angefasst aber nicht die neu angelegten in der lokalen db.
Ich mach glaube doch lieber while () wend und .addnew
Also:
Beim Neuerfassen im lokalen Frontend sollte ein "Dummy" vergeben werden. Dieser kann aus einer Funktion geholt werden, die den höchsten ID der Tabelle holt und um 1 erhöht. Dies geschieht NUR, weil im Feld "ID" etwas stehen sollte. Beim Updatestatement und auch beim Insert werden keine ID's mitgegeben.
Beim Zurückschreiben wird es nun etws interessanter. Eine Abfrage muss alle jene Datensätze UPDATEN, die bei beiden Tabellen vorhanden sind. Im zweiten Schritt werden all jene Datensätze, die NUR in der lokalen Tabelle vorkommen (zwangsäufig neue Datensätze) separat mittels INSERT INTO.. zurückgeschrieben.
Nun kann es auch sein, dass ein datensatz gelöscht werden sollte in der Backend-DB. Dies wird aber nur funktionieren, wenn der lokale Datensatz nicht gelöscht, sonden gekennzeichnet wird (zB. in einem Feld, zwei Underlines vorne an den Text schreiben). Dann heisst die Löschabfrage:
DELETE From <Frontendtabelle> WHERE ... (nur solche, die in der lokalen Tabelle mit "__" beginnen. Like-Operator benutzen)
Beim Neuerfassen im lokalen Frontend sollte ein "Dummy" vergeben werden. Dieser kann aus einer Funktion geholt werden, die den höchsten ID der Tabelle holt und um 1 erhöht. Dies geschieht NUR, weil im Feld "ID" etwas stehen sollte. Beim Updatestatement und auch beim Insert werden keine ID's mitgegeben.
Beim Zurückschreiben wird es nun etws interessanter. Eine Abfrage muss alle jene Datensätze UPDATEN, die bei beiden Tabellen vorhanden sind. Im zweiten Schritt werden all jene Datensätze, die NUR in der lokalen Tabelle vorkommen (zwangsäufig neue Datensätze) separat mittels INSERT INTO.. zurückgeschrieben.
Nun kann es auch sein, dass ein datensatz gelöscht werden sollte in der Backend-DB. Dies wird aber nur funktionieren, wenn der lokale Datensatz nicht gelöscht, sonden gekennzeichnet wird (zB. in einem Feld, zwei Underlines vorne an den Text schreiben). Dann heisst die Löschabfrage:
DELETE From <Frontendtabelle> WHERE ... (nur solche, die in der lokalen Tabelle mit "__" beginnen. Like-Operator benutzen)
super, so gehts auch, stimmt, ich probier mal was schneller ist
Danke.
Danke.
Ich wünsche ein schönes Wochenende und keine grauen Haare !!!
Mein Motto war es immer und ist es geblieben: In Access ist alles möglich, nur die Wege dazu sind manchmal etwas mühsam
Mein Motto war es immer und ist es geblieben: In Access ist alles möglich, nur die Wege dazu sind manchmal etwas mühsam
wie wahr wie wahr ... und jetzt muss ich noch 30 Zeichen auffüllen
