Neue Datensätze werden in Access als #Gelöscht in jeder Zelle angezeigt (sind aber vorhanden)

[micha1978]

Hallo Leute,

ich hoffe, jemand versteht die folgende Beschreibung und kann mir einen Tipp zur Fehlerlösung geben.

Ich habe eine alte DB (MS Access 2010) nach MariaDB geschoben und eine Zeitlang fehlerfrei mit dem Frontend Base mit den vorhandenen Tabellen arbeiten können.

Nun erfolgte der Umstieg auf Access 365 als Frontend. Verknüpfung mit ODBC erfolgreich, alle Tabellen da. Leider verhält sich in Access aber eine Tabelle im Umgang anders als die anderen.

1. Funktionierende andere Tabelle

Nachdem ich in einem neuen Datensatz ein Zeichen eingebe und dann aus dem Datensatz wechsle erscheint die ID (erste Spalte) und sonst nichts.

2. Nicht funktionierende Tabelle

Nachdem ich in einem neuen Datensatz ein Zeichen eingebe und dann aus dem Datensatz wechsle erscheint in allen Spalten #Gelöscht. Bei dem nächsten neuen Datensatz sieht es genauso aus. Schließe und öffne ich die Tabelle aber, sind die neuen Datensätze mit korrekter ID (erste Spalte) da.

Irgendeine Idee, woran dieses schräge Verhalten liegen könnte?

Hier noch kurz der CREATE code von MariaDB:
Tabelle 1. Funktionierende andere Tabelle
CREATE TABLE `bauteil` (
`ID` INT(11) NOT NULL AUTO_INCREMENT,
`Spalte1` VARCHAR(3) NULL DEFAULT NULL COLLATE 'utf8_general_ci',
`Spalte2` VARCHAR(8) NULL DEFAULT NULL COLLATE 'utf8_general_ci',
...
`Spaltex` MEDIUMTEXT NULL DEFAULT NULL COLLATE 'utf8_general_ci',
PRIMARY KEY (`ID`) USING BTREE
)
COLLATE='utf8_general_ci'
ENGINE=InnoDB
AUTO_INCREMENT=1268
;

Tabelle 2. Nicht funktionierende Tabelle
CREATE TABLE `egsbe_copy` (
`Spalte1` INT(11) NOT NULL AUTO_INCREMENT,
`Spalte2` MEDIUMTEXT NULL DEFAULT NULL COLLATE 'utf8_general_ci',
`Spalte3` VARCHAR(50) NULL DEFAULT NULL COLLATE 'utf8_general_ci',
`Spalte4` DATETIME NULL DEFAULT NULL,
`Spalte5` TIMESTAMP NULL DEFAULT current_timestamp() ON UPDATE current_timestamp(),
PRIMARY KEY (`Nr`) USING BTREE
)
COLLATE='utf8_general_ci'
ENGINE=InnoDB
AUTO_INCREMENT=4343
;

Danke im Voraus
Micha

 

[dabadepdu]

Du schreibst nichts darüber, wie vor oder nach der Umstellung auf 365 die Verwaltung der Primärschlüsselfelder erfolgt (Programm Code).
Ich habe keine Ahnung von aktuellen Access Version, und bei solchen "Breaking" Changes weiß ich auch, warum ich es nicht mehr nutze.

Es gab früher einen Verknüpfungsmanager. Dort konnten Table oder Query Links aktualisiert werden. Von dort, bzw. zu der jeweiligen Tabelle muss das System auch die Schlüsselfeldinformationen erhalten, sonst ist es "lost".

Kannst Du sicherstellen, dass diese Informationen da sind bzw. aktuell und für 365 nutzbar?

 

[micha1978]

Leider verstehe ich nicht genau, was mit "Verwaltung der Primärschlüsselfelder" gemeint ist. Aber beide Tabellen haben einen Primärschlüssel.

Wenn ich in den Entwurf beider Tabellen in Access schaue, den ich mir trotz der Warnung auf "keine Änderungsmöglichkeit in verknüpften Tabellen" anschauen kann, sind in beiden Tabellen die Primärschlüsselfelder gleich definiert.



Leider hatte sich in meinem ursprünglichen CREATE code für die Tabelle 2. ein Schreibfehler eingeschlichen, Spalte 1 ist auch hier der Primärschlüssel.

CREATE TABLE `egsbe_copy` (
`Spalte1` INT(11) NOT NULL AUTO_INCREMENT,
`Spalte2` MEDIUMTEXT NULL DEFAULT NULL COLLATE 'utf8_general_ci',
`Spalte3` VARCHAR(50) NULL DEFAULT NULL COLLATE 'utf8_general_ci',
`Spalte4` DATETIME NULL DEFAULT NULL,
`Spalte5` TIMESTAMP NULL DEFAULT current_timestamp() ON UPDATE current_timestamp(),
PRIMARY KEY (`Spalte1`) USING BTREE

 

[dabadepdu]

verstehe ich nicht genau, was mit "Verwaltung der Primärschlüsselfelder" gemeint ist

Ich kann es nicht genauer beschreiben, da ich kein Access mehr einsetze.
Grundsätzlich musst Du bei Primärschlüsselfeldern, die automatisch einen Wert bekommen (beim Insert), einen Mechanismus haben, der dem Client (Dein Access Frontend) mitteilt, (Primärschlüssel)Wert eingefügt, Wert=xy. In irgendeiner Form braucht der Client die Möglichkeit, die akut eingefügten Daten (inkl. ID) nach dem Insert zu erhalten bzw. abzufragen, also INSERT in der externen DB, Primärschlüssel dieses Inserts holen/bekommen, restliche Spaltenwerte nachladen (egal ob eingegebene oder generierte aus Spaltendefaultdefinitionen)
Welche Automatismen es da bei Access 365 gibt, weiß ich nicht.

Aber beide Tabellen haben einen Primärschlüssel.

Das ist gut. Vielleicht aber tückisch, weil es eine veraltete Information ist (vor 365). Das ist readonly, konnte aber früher mit dem Verknüpfungsmanager aktualisiert werden. Auch da weiß ich nicht, wie das heute ist.

Mglw. gibt es in den Forms Attribute, mit denen man das Verhalten von Access einstellen kann, mit denen man also festlegt, wie Access den Primärschlüssel bekommt. Wenn es das nicht gibt oder es nicht genutzt wird, muss es manuell mit eigenem Code gemacht werden.
Sonst kann(!) ein neu eingefügter Datensatz nicht richtig angezeigt werden, egal ob Access oder andere Clients.

 

[micha1978]

Wenn ich dich richtig verstehe, war das so ähnlich auch meine ursprüngliche Überlegung. Da Access sich erst mit dem Speichern eines neuen Datensatzes mit MariaDB abgleicht, ist dieser Mechanismus zumindest bei einer Tabelle gestört.

Ich werde mal versuchen, für Acces ein Makro für die Anlage eines neuen Datensatzes nach folgendem Muster zu erstellen (hoffe im www fündig zu werden):
1. Hole letzte (höchste) ID von MariaDB
2. Erhöhe ID um 1 und speichere in MariaDB
3. Lade letzte ID zum Bearbeiten

 

[dabadepdu]

Dazu eignet sich bei MariaDB vermutlich insert .. returning

INSERT

Insert rows into a table.

mariadb.com

Und ich vermute ebenso, dass es dem LAST_INSERT_ID Ansatz überlegen ist.

Wie man es in Access einsetzen kann (Rückgabe Parameter auslesen), weiß ich aber nicht.