Office: „Datensatz ist gelöscht”, was tun?

Hallo,
ich habe eine Datenbank, die von mehreren Nutzern bearbeitet werden kann.
Ab und zu passiert es, dass ein Feld „gelöscht” wird, d.h. der Datensatz wird zwar in der Tabelle noch dargestellt, doch in dem Feld steht nur ein „#” und der Inhalt lässt sich auch nicht mehr überschreiben.
Ich habe mich bisher in so einem Fall damit beholfen, dass ich den defekten Datensatz kopiert und neu eingefügt habe, dann versucht, den Inhalt der fehlenden Felder händisch im neuen Satz zu ergänzen und dann die Fremdschlüssel in den anderen Tabellen auf den neuen DS zu aktualisieren.
Schön wäre es natürlich, wenn man diese Störung irgendwie verhindern kann, aber ich weiß leider nicht wie und beschränke mich immer auf Brandlöschung.
Habt Ihr bessere Ideen?
Gruß
Doming

 

Guten Morgen,

Access verfügt ja leider nur über die blockweise Codeseitensperrung, was zu diesem Phänomen führt, wenn mehrere Benutzer auf die gleiche Datenbasis zugreifen. Abhilfe kann das Transaktionsmodell der Jet-Engine bringen.
Schau dir mal den Link an:
Transaktionen in Microsoft Access verwenden

 

Interessante Geschichte, vielen Dank.
Mal sehen, ob ich das vielleicht mal implementieren kann.

 

Mir ist es schleierhaft, welchen Zusammenhang du hier siehst.
Transaktionen werden ja - wie auch im verlinkten Artikel ersichtlich - automatisch verwendet.
Manuell gesetzte Transaktionen machen nur Sinn, wenn man mehrere Aktionen in eine Transaktion bringen will.
Aber da sehe ich keinen Zusammenhang mit dem Thema.

 

Kann denn der alte DS einfach gelöscht werden, oder was machst du mit dem?

Grundsätzlich:
Access im Netzwerkbetrieb ist für mich eher ein nogo.
Aber korrupte Daten kannst du auch bei jedem DB-Server haben.
Was du beschrieben hast, habe ich so noch nicht erlebt.
Ich nehme jetzt mal nicht an, dass du das Daten-Limit für einen Datensatz überschreitest.

 

Eine weitere interessante Möglichkeit ist die RecordLocks-Eigenschaft.

RecordLocks-Eigenschaft (DatensätzeSperren) - Microsoft-Support
Auch damit lässt sich das Phänomen #gelöscht managen, wenn einem manuelle Transaktionssteurung zu aufwendig ist.

Das Backend auf einem für die Benutzer zugänglichen Netzlaufwerk liegen zu haben ist in überschaubaren Umgebungen gängige Praxis, wenn man sich SQL-Server nicht leisten kann oder möchte und der zusätzlich Aufwand für andere DB-Server über das Ziel hinausschießt.
Backend in der Cloud lasse ich auch lieber sein.

Beste Grüße
Andreas

 

Hallo,
das Backend liegt auf einem Netzlaufwerk, und nein, ich denke nicht, dass ein Limit überschritten wird.
Der Datensatz lässt sich tatsächlich so löschen und es ist, wenn ich mich recht erinnere, nur ein Feld betroffen.
Es passiert jetzt nicht soo häufig, aber so ein bis zwei Mal im Jahr können es schon sein.

 

wo siehst du das eine Zusammenhang - was soll die Recordlocking Einstellung da verändern?
Was soll eine Transaktion verändern?
Ich sehe hier nichts was mit dem Problem zusammenhängt - du kannst aber gern eine Erklärung dazu liefern.

Auch die Argumentation gegen einen Server erachte ich für Unsinn zumal es ja überall kostenlos Versionen gibt, die aber allesamt weit höhere Datensicherheit und weit geringere Netzwerklast bieten können wie Access.
Access im Netzwerkbetrieb ist in der Regel eine weit schlechtere Lösung.
Sich darauf zu beziehen, dass Unwissende das dennoch machen ist ein Null-Argument.

@Doming, der Fehler ist sehr ungewöhnlich - hatte ich auch noch nie und es wird eher schwer sein da eine Lösung zu finden.

Korrupte Daten kenne ich z.B. daher, wenn versucht wird im Betrieb das Backend zu sichern.
Oder auch die Probleme mit der Fileserver Leasing Time, die aber von MS selbst verursacht wurden.

Helfen könnte da eine lückenlose Fehler-Protokollierung in Verbindung mit einem Änderungsprotokoll der Daten.
Wie erfährst du überhaupt von dem Problem - melden das die User, oder wie läuft das ab?
Kann mir nicht vorstellen, dass es da zu keiner Fehlermeldung kommt.
Handelt es sich immer um die gleiche Tabelle?
Was hat das betroffene Feld für einen Datentyp?

 

Hallo Markus,
Recordlock ist Englisch und heißt "Satz gesperrt". Aber mein Englisch ist wohl nicht so gut..;-) ....

Aktionen unter einer Transaktion zusammenzufassen hat man schon 1983 bei IBM mit CICS gemacht. Lässt vermuten, dass es einen Versuch wert ist dem Fehler auf die Spur zu kommen oder ihn vielleicht sogar zu beheben.

Ich habe nicht gegen Server im Allgemeinen argumentiert. SQL-Server o.ä. müssen aber eben unabhängig von Access verwaltet werden, was zusätzlichen , ggf. auch finanziellen Aufwand erfordert, der für kleine Anwendungen sicher nicht immer erforderlich ist. Und alle, die die einfache Netzwerklösung nutzen, als Unwissende zu bezeichnen ist schon recht anmaßend.

Es sind also bisher nur Fragen und Vermutungen geäußert obwohl:

Vielleicht bringen die Antworten auf die gestellten Fragen Licht ins Dunkel.

Ach so, und oben mal ein Hallo und am Ende Grüße
fördert die Kommunikation mehr als direkt los zu poltern.

Beste Grüße
Andreas

 

Moin,
vor einigen Jahren, als ich die DB geschrieben habe, durfte ich sie auch selber noch bearbeiten, mittlerweile sitze ich in einer anderen Abteilung und man erinnert sich meiner, wenn mal was schief läuft ;-)
In der DB geht es um Prüfberichte, von der einen Abteilung erstellt und von anderen weiter bearbeitet.
Das defekte Feld ist vom Typ „Langer Text”/Memo, welches eigentlich nach dem Abschicken nicht mehr geändert wird.
Da der Bericht nach der Erstellung auch als PDF verschickt wird, ist es kein großes Problem, den Text im neuen Datensatz wiederherzustellen, aber das „#Gelöscht” macht die Weiterbearbung natürlich etwas holperig :-)
Bemerkt wird der Fehler meistens dadurch, dass der Export in eine Exceldatei nicht mehr möglich ist.
Gruß
Doming

 

Hallo,
das #Gelöscht erscheint ja normalerweise in allen Feldern einer (primär) geöffneten Tabelle, wenn währenddessen über ein (Unter)Formular der Satz gelöscht wird. Es löst sich auf, wenn die Tabelle geschlossen und wieder geöffnet wird. Dann ist der Satz weg. (Beziehung natürlich mit ref Int.)
Der gleiche Effekt entsteht im Formular, wenn parallel in der Tabelle der Satz gelöscht wird. Auch dort löst es sich auf, wenn ein Refresh durchgeführt wird.
Bist Du, wenn das Problem auftritt, denn immer sicher, dass alle Frontends geschlossen wurden, bzw. sind?

 

Ich bin mir ziemlich sicher, dass dann NICHT alle Frontends geschlossen sind. Ich vermute, dass zu dem Zeitpunkt irgendjemand irgendwas am DS ändert bzw. geändert hat und als Abfallprodukt geht das Feld hops.
Gruß
Doming

 

Hallo,
Was ist, wenn Du einfach die Erlaubnis zu löschen über die Formulareigenschaft ausschaltest? Sondern nur ein Löschkennzeichen setzt, wenn der Satz nicht mehr relevant ist. So macht man es ja auch, zum Beispiel bei Artikelstammdaten o.ä., damit man zwar weiß, der Satz ist nicht mehr relevant, aber die gesamte Historie der Untertabellen, z.B. Bewegungen, bleiben erhalten.

 

hm, Moment, da wird eine Miss verstanden.
Die Datensätze können von den Mitarbeitern gar nicht gelöscht werden. Sollten sie irrtümlich erstellt worden sein, werden sie als „zurückgezogen” markiert, es läuft ein Protokoll mit, in dem jede Statusänderung angezeigt wird.
Die #gelöscht-Markierung passiert nur unwissentlich, weil der DB irgendwas nicht passt :-)

 

Memo Felder haben Besonderheiten. Der Inhalt kann gänzlich oder teilweise im selben Datensatz gespeichert werden.
Spannend wird es erst dann, wenn zusätzliche Textfelder die zuvor leer waren einen Inhalt erhalten, weil es dadurch mitunter zu dem Problem kommt, dass eine Datensatzlänge überschritten wird.
Das könnte man aber mal testen um zu sehen, ob man das nachstellen kann - das sollte ja eigentlich möglich sein.
Ich nehme an Komprimieren wurde auch erfolglos versucht.