Office: (Office 2003) Kombinationsfeld & MySQL: Verzweiflung

Hi,

ich habe ein einfaches Formular in MS-Access, welches auf eine verknüpfte MySQL-Tabelle zugreift.
Im Formular findet sich ein Kombinationsfeld zur Auswahl von Werten für eines der Datenbankfelder.
Soweit funktioniert auch alles gut...

Wenn ich aber im Kombinationsfeld den selben Wert auswähle, der bereits in der Datenbank steht, erscheint im Formular das Dirty-Symbol. Nur: Speichern kann man den Datensatz dann nicht: Schreibkonflikt! Dieser Datensatz wurde seit Beginn der Bearbeitung von einem anderen Benutzer geändert...
Dabei wurde in diesem Fall doch "eigentlich" GAR NICHTS geändert.

Auch wenn man ringweise ändert: Angenommen die Anrede steht auf "Herr". Über das Kombinationsfeld wähle ich nun "Frau". Und wieder "Herr" (ohne zwischendurch zu speichern). Wieder ist speichern nicht möglich: Schreibkonflikt.

Das Ganze ist für den späteren Anwender mehr als lästig.

Die Tabellen in MySQL haben auch Timestamp-Felder.

Weiß jemand Rat??? Ich habe schon versucht die Kombinationsfelder unabhängig zu machen und die Daten per Script in die Datenbank zu übertragen - das wäre aber massenhaft Aufwand, da es eine Portierung einer reinen Access-Applikation auf Access/MySQL ist und es eine Menge Kombinationsfelder gibt...

Ciao, Udo

:)

 

Wenn ich Dich richtig verstehe, willst Du mit dem Kombinationsfeld etwas suchen.
Dann muss das Feld auch 'ungebunden' sein und nicht den Inhalt eines Felds der entsprechenden Tabelle darstellen.

Somit würde eine Änderung des Werts im Kombifeld eine Änderung des Werts im Datensatz bewirken.

 

Moin Udo,
da hast Du das Prinzip der gebundenen Formulare in Access noch nicht ganz intus: alle Controls sind an die entsprechenden Felder in der Datenquelle gebunden, d.h. wenn Du eins änderst, befindet sich der entsprechende Datensatz im Zugriff und - je nach zugrundeliegender Datenbank - im Bearbeitungsmodus. Die Access Jet-Engine speichert geänderte Datensätze ja auch einfach ab, wenn man den Datensatzzeiger vom geänderten Satz wegbewegt.
Wenn Du das alles nicht willst, musst Du ungebundene Formulare aufbauen. Bei denen musst Du Dich aber um das Laden und Speichern selbst kümmern.

 

Ich weiß, dass die Felder an die Datenbank gebunden sind und das Änderungen natürlich bewirken, dass beim speichern der Datensatz überschrieben wird. Das ist ja auch völlig ok und beabsichtigt. Funktioniert ja auch problemlos, wenn ich aus dem Kombinationsfeld einen neuen Wert für das Datenbankfeld wähle.
Nur wenn ich den Wert wähle, der bereits in der Datenbank steht (direkt, oder auf dem Umweg über einen anderen Wert), kann ich den Datensatz nicht speichern: Schreibkonflikt. Und das ist zum Mäusemelken... Es sollte doch völlig egal sein, welchen Wert ich in das Kombinationsfeld eingebe (es wird eine Zeichenkette ausgewählt und das Datenbankfeld ist auch eine Zeichenkette - zusätzlich können "freie Werte" eingetippt werden.
Das Verhalten ist vollkommen reproduzierbar und einfach schwachsinnig... Die Werte für die Liste des Kombinationsfeldes kommen aus einer anderen Tabelle (wahlweise auch in der Remote-Datenbank oder auch lokal als Access-Tabelle - Resultat ist identisch). Ich möchte damit z.B. die Anrede bequem auswählbar machen.

Also steht als Datenquelle für das Kombinationsfeld (welches an das Datenbankfeld "Anrede" gekoppelt ist) eine Tabelle die die Werte "Herr", "Frau", "Familie", "Eheleute" enthält.
Nun gebe ich einen neuen Datensatz ein:
"Herr", "Anton", "Müller"
und speichere diesen. Soweit kein Problem.
Klicke ich nun auf das Kombinationsfeld, merke, dass ich das doch nicht wollte und klicke daher wieder auf "Herr", so kann ich den Datensatz nicht mehr speichern: Schreibkonflikt. Drücke ich stattdessen "ESC" geht es natürlich problemlos (aber welchem Endanwender kann man DEN Unterschied klar machen???).

Wähle ich stattdessen "Frau", merke, dass das falsch ist und wähle sofort wieder "Herr" (ohne zwischendurch zu speichern), kommt wieder der Schreibkonflikt. Habe ich zwischenzeitlich weitere Änderungen in der Maske vorgenommen, sind diese damit verloren. Ausgesprochen ärgerlich für den Anwender...

Ciao, Udo

 

Die Änderung an dem bestehenden Datensatz wird als Änderung (auch wenn Du wieder den ursprünglichen Wert einstellst) angesehen.
Diese ist offenbar nicht zulässig, deswegen kommt die Meldung.

 

Aha... Warum sollte diese Änderung nicht zulässig sein? Ich stelle schließlich keinen anderen Wert ein als den, der schon drin steht. Und im Moment bin ich alleiniger Benutzer. Es KANN also eigentlich keinen Schreibkonflikt geben.
Wenn ich einen anderen Wert auswähle (also z.B. von "Herr" auf "Frau" wechsele), funktioniert ja schließlich auch alles bestens.
Ich verstehe es einfach nicht :-(

Ciao, Udo

 

Gibt es Ereignisprozeduren bzgl. des Kombifeldes? Oder sonstigen Code im Klassenmodul des Formulars?
Das Hin- und Herändern des Datenfeldes allein kann diesen Effekt nicht auslösen.

 

Es gibt Ereignisprozeduren zu verschiedenen Bereichen, aber nicht direkt mit dem Kombinationsfeld. Ich habe es aber auch mal "nackt" getestet. Einfach ein leeres Formular an die verknüpfte Tabelle gebunden, ein Kombinationsfeld und 2 weitere Datenfelder eingebaut. Das Ergebnis ist das selbe :-(
Ich hätte ja vorher auch gesagt: Das kann nicht sein... Ist aber :-(

Ciao, Udo

 

Genau darauf wollte ich ja hinaus: Nämlich dass evtl. per Code Datensatzänderungen vorgenommen werden, die mit deinen Eingaben in Widerspruch stehen oder sonstwie in Konflikt...

Ließe sich dazu evtl. eine Demo-DB hochladen?

 

Ich glaube, ich habs jetzt...

Ich hatte eine zweite Access-Applikation geöffnet, die allerdings mit völlig anderen Daten auf einem eigenen Access-Backend arbeitet. Im Klartext: Die beiden Applikationen haben keinerlei gemeinsame Daten, arbeiten nicht mal auf einer gemeinsamen Datenbank. Eine ist Access pur, eine Access + MySQL.

Ich hatte die andere nur offen, weil ich dort (es ist eine alte Version der Applikation) abschauen muss....

Wenn ich beide Applikationen gleichzeitig offen habe, passiert der beschriebene Fehler. Auch, wenn ich anschließend die "alte" Applikation schließe, bleibt der Fehler bestehen. Öffne ich aber die neue Applikation als erste und einzige, so taucht der Fehler nicht mehr auf...

Erklären können muss man das wohl nicht, oder???

Ciao, Udo

 

Ich würde mir mal die Tabelleneinbindungen in der alten DB genauer anschauen... *wink.gif*

(es gibt nur sehr wenig, was man wirklich nicht erklären kann...)

 

Da gibt es nichts zu schauen. Die alte Datenbank greift auf ein Access-Backend zu. Die Neue ausschließlich auf lokale Access-Tabellen und auf MySQL remote. Da gibt es keinerlei Gemeinsamkeiten.
Außerdem wurde ja während der Versuche in der zweiten Datenbank überhaupt nichts gemacht. Das Ding war zwar offen, wurde aber nicht bedient. Es ist auch völlig unerheblich, ob in der alten DB irgendein Formular geöffnet ist oder nicht...

Da kommt Access wohl irgendwie intern etwas durcheinander...

Ciao, Udo

 

Halte ich eigentlich für ausgeschlossen *wink.gif*
Access macht nur in den seltensten Fällen wirklich selbständig und eigenwillig etwas *biggrin.gif*

Hast Du möglicherweise zu Testzwecken in der alten DB die Tabellen des MySQL-Servers eingebunden?
Gibts evtl. einen Code der auf die Daten zugreift?

Offensichtlich baut diese "alte" DB irgendwo eine Connection zum MySQL-Server auf. Und das tut sie nur, wenn es ihr gesagt wird/wurde.

 

Nein - definitiv nichts dergleichen.

Ciao, Udo