MS Access mit Backend mySQL

Computer: Software & Programmierung Visual Basic
#1

Hallo zusammen,
ich verwende MS Access 2016 als Backend für einen mySQL-Server. Nach Migration der Access-Datenbank kann ich bereits vorhandene Datensätze über das Access-Formular bearbeiten. Wenn ich jedoch einen neuen Datensatz über den mySQL-Server anlege, ist das zwar möglich, jedoch bei jeder Änderung eines Feldes erscheint beim Abspeichern

Dieser Datensatz wurde seit Beginn der Bearbeitung von einem anderen Benutzer geändert. Wenn Sie den Datensatz speichern, werden Sie die Änderungen des anderen Benutzers überschreiben.

Ich kann den Datensatz aber leider nicht speichern, da die betreffende Schaltfläche deaktiviert ist.
Der auftretende Fehler hat die Nummer 7787

Folgende gängigen Maßnahmen habe ich schon ergriffen:

  • setzen eines Primary Keys
  • einfügen eines TimeStamp Feldes
  • Konvertieren der Double Felder in DECIMAL
  • Anpassen der „Corsor-Results“ in der ODBC-Datenquelle

Hat evtl. jemand einen Tipp für mich, was ich noch falsch mache?
lg Clemens

#2

Die Sicherheitsupdates vom 14. Dezember 2021 für Microsoft Office (MSI-Installer-Version) verursachen Probleme mit Microsoft Access. Es kann nur noch ein Nutzer auf die Datenbanken zugreifen. … Das betrifft auch die Access 2013/2016 Runtime, die von manchen Nutzern eingesetzt wird. Quelle

#3

Und was hat das außer genau nichts mit dem Problem zu tun?

@ClemensKeil
Das Problem ist ein ziemlich skurriles und altes: Du änderst einen Wert, somit wird der Datensatz quasi als „in Bearbeitung“ markiert und keiner darf jetzt „ändernd“ darauf zugreifen - vor allem aber du selber auch nicht mehr.
Du sollst das Formular auf „nicht bearbeitet“ (Me.Dirty = False) setzen und dann den Datensatz funktional per Update in die Datenbank schreiben.

Allerdings kann es dein Problem auch nicht lösen, hast du hier schon nachgesehen?

#4

Deine Frage sieht so aus, dass du mit Multiuser-Datenbanken keine Erfahrung hast.

Clemens hat nicht verraten, mit welchem Programm er das macht (phpMyAdmin?), jedenfalls nicht mit MS Access. Und damit ist er ein anderer User als der Access-User.

#5

Ist es nicht eher umgekehrt?

#6

Bin ich auch drüber gestolpert, aber die Überschrift behauptet das Gegenteil.

#7

Du meinst, er wollte eigentlich Frontend statt Backend schreiben? :slight_smile:

Und das darf man nicht in Frage stellen, oder wie?

#8

Kann man, wenn man Nicht-Kenner langweilen will. Für einen Fachmann sollte klar sein, dass mySQL eine Server-Software ist, also „back“ (hinten aus der Sicht des Anwenders). Was auf dem Display erscheint, ist „front“.

Du hast dich doch auch schon fachgerecht zu IT-Themen geäußert, warum kommen dir hier Zweifel?

#9

Der Fragesteller ist aber offensichtlich kein Fachmann, sonst würde er nicht solche grundlegende Fachbegriffe falsch verwenden. Also kann man das durchaus erstmal mit ihm klären, damit man eine gemeinsame Sprache spricht.

#10

Hallo Axurit,
du hast völlig recht. Acces ist natürlich der Frontend…

#11

Hallo zusammen, kurzer Zwischenkommentar: also zuerst mal herzlichen Dank für die Rückmeldungen. Toll, dass etliche User*innen hier bereit sind, ihre kostbare Freizeit für EDV-Probleme anderer zu opfern.
Zur grundsätzlichen Beruhigung darf ich versichern, dass ich mich schon ein bissl auskenn. Ich bin ausgebildeter Telematiker der TU (das sagt natürlich nix), hab sehr viel Erfahrung von früher mit C++ bin mit dBASE und Clipper groß geworden und verwende seit 1996 Access Datenbanken. Mit PHP kenn ich mich kaum aus, daher der Wunsch, meine Access-Oberflächen an einen mySQL-Server anzubinden. Dort steh ich grad an, die Tipps von PeterSilie und Tomh erscheinen vielversprechend zu sein, ich werd das mal ausprobieren und mir erlauben, euch zu berichten. lg

#12

Also das angesprochene Zugriffsproblem mit Access Datenbanken (nur ein User) ist - wenn ich den Artikel richtig verstanden habe - auf File-Sharing Basis. Das betrifft meinen Fall nicht.
Wobei der Fehler, den Access auswirt (7787) ein unspezifizerter ist.

Zu den Detailfragen: den mySQL (8.0, ich hab dasselbe aber auch mit 5.7 probiert) administriere ich mit phpMyAdmin. Der Frontend läuft auf Access2016 (hab ich eingangs falsch beschrieben - sorry nochmals).
Die dirty-Eigenschaft lässt sich per code nicht ausschalten, da spuckt mich Access wieder an.

Was besonders bemerkenswert ist: ich hab bei der Migration 80 in Access angelegte Datensätze auf den mySQL-Server ausgehend von Access exportiert. Dann in mySQL PK und Timestamp gesetzt und die Tabellen in Access über den ODBC Connector verknüpft.
Und jetzt kommts: die bereits vorhandenen Datensätze kann ich beliebig direkt aus dem Formular (ohne RS.Edit und Update) ändern. Lediglich die nach der Migration neu angelegten Datensätze zicken… Dieses Phänomen hab ich in den diversen Foren noch nicht beobachtet.

#13

Fast keine - arbeite erst 35 Jahren mit Oracle (u.a. auch als DB-Admin), SQL-Server, TerraData, Informix (lang ist’s her), usw. - mit den verschiedensten Frontends.

Er beschreibt (im UP) hier klar, um welche zwei Schritte es hier geht:

  1. Schritt: Er ändert das Feld (die Session locked den Record in der DB)
  2. Schritt: Er will nun das Commit absetzten, der Record ist aber gelocked.

Zusätzlich hat er noch bekannt gegeben, dass das nur bei neuen Sätzen passiert.

Ein altes Problem, das bei DB-Zugriffen über Fremdsysteme nicht unbekannt ist, auch wenn sein letzter Eintrag etwas anderes vermuten lässt.

Das hat alles nix damit zu tun, ob das eine „Multiuser-Datenbank“ ist oder nicht.

Also von hinten aufrollen: Wo liegt der Unterschied zwischen den „neuen“ und den „alten“ Sätzen? Vor allem bei nicht ganz so standardisierten Datentypen? Schlagen ev. DB-Trigger zu?

Was passiert zwischen der Eingabe eines neuen Satzes und der Änderung von diesem (auf der Datenbank)? Wird explizit gespeichert?

1 Like
#14

Guten Morgen, zusammen. Ich habe den Eindruck, dass sich hier alle - sogar inkl. meiner Wenigkeit :slight_smile: nicht allzu schlecht auskennen - bis auf mein schlampiges Wording.
Tom, nach einer kurzen Nacht gehe ich davon aus, dass du recht hast, möglicherweise passiert in irgendeinem der 120 Felder etwas, was für Access kein Problem war, dem mySQL Server aber nicht passt. Ich hab als letzte Aktion bis auf PK, Timestamp und ein paar banalen Texteingabefeldern alles rausgeschmissen, und siehe da, jetzt geht es auch mit neuen mySQL-Datensätzen. D.h. ich werde nach Quicksort vorgehen und immer die Hälfte der Felder eliminieren, dann muss ich das ld120 mal machen (also max. 7 Durchläufe) und sollte dann den Schuldigen finden (außer es sind mehrere). Ich hab aber auch hier einen Verdacht, da ich zwei Textfelder mit einem Standardstring bei Neuanlage vorbelegen lasse. Hab mal wo was gelesen, dass der mySQL-Server manchmal Felder mit Blanks zukleistert…
Hoffe ich komm so zu fahren. Danke auf jeden Fall für eure Zeit, auf mein Problem eingehen zu wollen.
Sollte es ein Ergebnis geben, werde ich euch berichten, ansonsten kehre ich reumütig zu lokalen Single-User DBs mit reinen Access-Tabellen zurück :wink:

1 Like
#15

Für alle, die es interessiert, und vielleicht hilft es auch irgendwo mal weiter: es waren die Bool’schen Variablen. Die wurden bei Neuanlage Standardmäßig mit dem Wert NULL belegt, was keinen Sinn macht, denn somit hat die Variable mit b0 und b1 3 Optionen. An diesem Widerspruch scheint sich der mySQL Server aufgehängt zu haben. Das erklärt auch, warum bereits importierte Datensätze funktioniert haben, da beim Import 0 oder (im Falle Access -1) übermittelt wurden.
Wie sooft: banaler Hintergrund - gravierende Auswirkung.
Die Accessdatei stürzt mir dennoch dauernd ohne spezifischen Fehler ab, das wird die nächste Baustelle, aber das Kernproblem ist gelöst.
Danke für’s Mitposten

#16

Auch wenn es für manche schwer zu verstehen ist: NULL ist von großer Bedeutung - auch für Boolean -, denn es ist ein großer Unterschied zwischen (am boolschen Beispiel), ob der Wert true, false oder das Attribut eben nicht gesetzt, also unbekannt ist.

Und ja, genau deswegen hat boolean eigentlich drei Zustände: true, false, null

1 Like
#17

Auch wenn es für manche schwer zu verstehen ist, macht es bei einer logischen Variable logischerweise keinen Sinn. Weil ich mit einer Aussage Ja - Nein - Vielleicht schlichtweg NICHTS aussage und mir so eine Variable schenken kann (den mySQL-Server und Access hat es bei dieser Frage ja auch ordentlich durcheinandergewürfelt, und sie waren sich offensichtlich nicht einig). Die Sinnfrage erscheint mir da schon fast philosophischer Natur zu sein. Was hingegen definitiv Sinn macht, ist ein gepflegter, nicht überheblicher Umgangston in Diskussionsforen, was hingegen auch für manche schwer zu verstehen zu sein scheint.
Wikipedia sieht das mit zwei Zuständen für Bool’sche Variablen übrigens ähnlich wie ich - zumindest was den Programmiersektor anbelangt
Boolean – Wikipedia

#18

Und auf welchen Wert setzt du Boolean, wenn du den Zustand nicht kennst?

Nicht umsonst gibt es bei den großen Datenbanksystemen (Oracle, SQL-Server, etc.) den Datentyp Boolean gar nicht, weil er eben Probleme macht, sich eben mit dem NULL „nicht verträgt“.
Da behilft man sich eben mit anderen Datentypen und Constraints.

Boolean wird - in Programmen - für etwas benutzt, was nur zwei Zustände haben kann, und das ist bei einem Datenbankattribut, das eben auch keinen Wert haben kann - aus welchen Gründen auch immer -, nun einmal nicht der Fall.

1 Like
#19

Es gibt durchaus einen Sinn für die Abfrage von Datenbankfeldern, ob diese „gefüllt“ sind oder eben nicht. ( bzw. definiert oder nicht definiert).
So kann es Prozesse geben, wo verschiedene Personen mit Hilfe unterschiedlicher Eingabeformulare Daten eingeben können und diese Dateneingabe könnte u.a. dadurch unterschiedlich gesteuert/gefiltert werden - abhängig davon, ob für ein Datenfeld bereits eine Eingabe (also z.B. eine Auswahl 1/0 oder Ja/Nein) erfolgte oder eben nicht…

Beatrix

#20

Mal ein ganz konkretes Beispiel, das bei jedem von uns zuhause tagtäglich anzutreffen sein könnte. Du hast eine kleine Hausautomatisation mit diversen Lichtschaltern, Türkontakten, … Auf den ersten Blick erscheint es erst einmal einleuchtend, dass so ein einfacher Lichtschalter oder Türkontakt nur ein/aus bzw. offen/geschlossen sein kann. Nun arbeiten diese Systeme aber überwiegend über diverse Funkstandards, die auf Energiesparen getrimmt sind, und daher nicht ständig hin und her kommunizieren, sondern dies nach gewissen Notwendigkeiten machen. Kommt es hierbei zu Störungen macht es einen erheblichen Unterschied zu wissen, ob der Türsensor einfach nur noch nicht wieder initialisiert wurde (Null) oder die Tür sicher offen oder geschlossen ist, wenn Du darauf basierend einen Alarm auslösen möchtest. Daher tut man bei der Konzeption einer solchen Lösung gut daran, diesen Status „Null“ immer mit zu berücksichtigen und z.B. bei einem Neustart des Systems hierauf in geeigneter Art und Weise zu reagieren, bevor das Ding anfängt Amok auf Basis tatsächlich unbestätigter Zustände zu laufen.

Bei vielen Datenbank-basierten Lösungen gibt es auch Batchläufe, in denen erst zu einem gewissen Zeitpunkt - unabhängig von manueller Erfassung - Felder in Datensätzen gefüllt oder verändert werden. Auch da ist es oft so, dass Bool-Werte bis zu einem solchen Batchlauf noch gar nicht initialisiert sind, und dann natürlich auch entsprechend repräsentiert werden müssen, damit keine falschen Schlüsse aus tatsächlich noch nicht gesetzten Werten gezogen werden.

BTW: Ich wollte auf deine Ursprungsfrage antworten, dass ich mal ein vergleichbares Problem hatte, konnte mich aber schlicht und ergreifend nicht mehr daran erinnern, was damals die Lösung war (die ich dann auch mit einer Betrachtung der einzelnen Felder irgendwann gefunden hatte). Ich bin mir jetzt aber ziemlich sicher, dass es auch bei mir damals Bool-Werte waren :wink: