Office: (Office 2010) Inhalt un-/gebundener Textfelder erst nach Klick auf "Speichern"

Hallo, ich bin's mal wieder *wink.gif*

Ich bin wieder auf neue Probleme gestoßen.
Ich habe ein Anzeigeformular zur Anzeige von Ansprechpartnern und allen daran hängenden Informationen. Alle Steuerelemente sind gesperrt, damit keine Eingabe möglich ist.
Hier erfolgt die Auswahl des Ansprechpartners über 3 Kombinationsfelder: 1. Auswahl der Firma, 2. Auswahl der Niederlassung, 3. Auswahl des Ansprechpartners. Funktioniert auch alles... jetzt will ich aber über ein weiteres Formular den geöffneten Ansprechpartner bearbeiten ( z.B. eine Telefonnummer ändern) und hier kommen auch die Probleme:
In dem Bearbeitungsformular habe ich alle Felder 2 mal (zu Testzwecken), je ein Mal an die Tabelle tblAnsprechpartner gebunden und ein Mal ungebunden, welche gefüllt werden, indem im Anzeigeformular alle nötigen Textfeldinhalte via TempVars abgespeichert und dann im Bearbeitungsfrm. ausgelesen und die Textfelder damit gefüllt werden.

Die ungebundenen Felder, welche über die TempVars gefüllt werden, werden so auch einwandfrei übernommen, nur wenn ich jetzt auf SPEICHERN klicke, legt Access theoretisch mit dieser Prozedur ja automatisch eine neue ID_AN für den (alten) Ansprechpartner an, da das Feld ID_AN ein Autowert ist. Praktisch bekomme ich eine Fehlermeldung (siehe Anhang), da in der Tabelle tblAnsprechpartner die ID_AN ein Autowert und der Primärschlüssel ist:

Code:

Die zweite Alternative: mit den gebundenen Textfeldern wollte ich über einen Filter in der RecordSource - Eigenschaft des Formulars über die ID_AN aus dem Anzeigeformular anzeigen lassen. Die Filterprozedur steht im Form_Load Ereignis. Nur klappt das so nicht recht, wie ich mir das vorgestellt habe.

Code:

lgID_AN_NEU ist nur für das Formular nutzbar und wird mit dem Inhalt der TempVars-Variable gefüllt, welche ihren Wert bereits im Anzeigeformular erhält. Der Wert wird auch korrekt aus dem Anzeigeformular übernommen (dazu das txtID_AN_1). Nur das Filtern funktioniert nicht so, wie ich es mir gedacht habe. Ein weiteres Problem, was ich bei den gebundenen Feldern noch sehe, ist die Tatsache, dass bei der Eingabe der Datensatz ja sofort in der Tabelle geändert wird. Das soll aber erst geschehen, wenn der Anwender auf SPEICHERN klickt bzw. es soll gar nicht gespeichert werden, wenn der Anwender auf ABBRECHEN klickt.

Nun mal meine genauen Fragen:
1. Alternative für ungebundene Felder:
Wie bekomme ich es realisiert, dass wirklich der vorhandene Datensatz geändert wird und nicht versucht wird einen neuen Datensatz mit teilweise "alten" Informationen zu schreiben, die dann beim Punkt ID_AN zum Fehler führen?!
Evtl den "alten" Datensatz vor dem eigentlichen Speichern löschen und dann einen neuen Datensatz anlegen mit der alten ID_AN?! Dann dürfte es ja keine Probleme damit geben, dass die ID_AN doppelt auftritt...oder?

2. Alternative für gebundene Felder:
Wie kann ich das automatische Sichern "aufhalten" bis der Button SPEICHERN geklickt wird und die Eingabeüberprüfung (alle Pflichtfelder gefüllt) durchlaufen ist? Andererseits sollen die Änderungen nicht gespeichert werden, wenn auf ABBRECHEN geklickt wird.

Ich hoffe ich konnte mein Anliegen gut verständlich erläutern *wink.gif* und bin auf hilfreiche Antworten gespannt, VIELEN DANK schon mal im Vorraus!!!

MfG Felix

EDIT 14:41 : Habe jetzt den Primärschlüssel aus der Tabelle entfernt und das Speichern funktioniert jetzt. Das Problem ist aber, dass der eigentlich zu bearbeitende Datensatz nicht angetastet wird und unverändert weiter besteht und lediglich ein neuer Datensatz mit alter ID_AN erstelllt wird, welche dann doppelt in der Tabelle auftritt. Das darf aber/soll aber nicht so sein, da diese ID_AN schließlich den Ansprechpartner eindeutig identifiziert.

:)

 

Wie schon in dem anderen Thread auch hier nochmal der Hinweis:
Vergiß (in diesem Zusammenhang) die ungebunden Variante; die macht nur unnötigerweise Ärger/Aufwand.

Anhand des Primärschlüssel lässt sich ein Datensatz eindeutig identifizieren.
Um Änderungen am Datensatz nur durch explizites speichern zuzulassen gibt es verschiedene Möglichkeiten auch bei gebundenen Formularen.
Hierzu kann z.B. im BeforeUpdate-Ereignis des Formulars geprüft werden ob die Daten verändert wurden und sich diese z.B. durch eine MessageBox bestätigen lassen oder wieder verwerfen.

Wenn Du unbedingt bei der ungebundenen Variante bleiben möchtest solltest Du diese nicht mit gebundenen Formularen "mischen"; das wird unweigerlich zu Fehlern oder "Datenmüll" führen...

 

Diese "Mischung" aus gebundenen und ungebundenen Feldern hat in diesem Fall ja nur aus Testgründen stattgefunden. Es gibt auch keine Verbindungen zwischen gebundenen und ungebundenen Feldern. Weder so im Formular, noch irgendwo im VBA-Code.
Und zu den ungebundenen Feldern kann ich nur sagen, dass so wenigstens die korrekten Daten zum Bearbeiten angezeigt werden. Hier besteht aber jetzt das Problem, dass wenn der Primärschlüssel entfernt ist, dass Speichern an sich zwar funktioniert, aber der alte eigentlich zu ändernde Datensatz weiter so (unverändert) bestehen bleibt und ein neuer Datensatz angelegt wird, bloß halt mit der gleichen ID_AN. So gibt es eine ID_AN 2 mal und das ist ja nicht Sinn und Zweck der Sache.

Bei den gebundenen Feldern besteht weiterhin das Problem, dass ich den Filter scheinbar nicht richtig setze bzw. nicht genau weiß wie ich das ganze richtig umsetze.
EDIT: Doofer Fehler meinerseits: das Filtern funktioniert jetzt für die gebundenen Felder. Code:

Zwischenzeitlich habe ich noch nach anderen Wegen gegoogelt und bin auf folgendes gestoßen:
https://msdn.microsoft.com/de-de/lib.../ff845201.aspx

Unter dem Punkt "Aktualisieren von Datensätzen in einer Tabelle" steht diese UPDATE -Funktion beschrieben. Weiß jemand damit umzugehen? Kann ich das einfach folgendermaßen hinter die Speichern_Click() Prozedur schreiben?
Code:

Hat jemand damit schon mal Erfahrungen gemacht?

 

Der von Dir gefundene Artikel bezieht sich wieder auf ungebundene Formulare... *rolleyes.gif*

Frage:
Möchtest/Musst Du zwingend mit ungebundenen Formularen arbeiten?
Oder ist es alternativ auch möglich mit gebundenen Formularen zu arbeiten wenn die gewünschte Funktionalität "Daten werden nur durch explizites speichern (z.B. per Button) verändert" umgesetzt wird?

 

Ja. Der Umgang mit SQL (hier: Aktualisierungsabfrage) ist für jeden ernsthaften Accessler nicht Kür, sondern Pflicht.

In Deinem Code fehlt allerdings noch der Bezug auf den konkreten Datensatz, den Du verändern möchtest (WHERE-Klausel in SQL).

Aber: Siehe Bennys #4!

 

Guten Morgen,
@CptChaos: Im Grunde ist es mir egal, ob es ungebundene oder gebundene Formulare sind, hauptsache ich bekomme es so hin, dass es nachher einwandfrei funktioniert *wink.gif*
Für die gebundenen Formulare bräuchte ich mal eine eindeutige Erklärung, wie das Speichern erst durch Button-Klick funktioniert?!

@maxel: Ich habe jetzt mal die UPDATE-Funktion ausprobieren wollen in Bezug auf die ungebundenen Felder, ich bekomme aber einen Fehler sobald ich Code verlassen will mit dem Cursor (Fehler beim Kompilieren: Erwartet: Anweisungsende)
Code:

ID_AN ist die einmalige/ eindeutig zu identifizierende "ID" und lgID_AN_NEU wird gleich im Private Sub Form_Load() beschrieben. Also sollte der Bezug auf den konkreten Datensatz gegeben sein.

Irgendwas an dem Syntax der UPDATE-Funktion habe ich ganz offensichtlich falsch interpretiert und umgesetzt.

EDIT: Habe noch eine andere Variante für den Syntax der UPDATE-Funktion ausprobiert, funktioniert aber auch nicht an Stelle des "WHERE"
Code:

Das Feld in der Tabelle heißt natürlich ID_AN, wo auch selbiges drin steht... Aber an genau der Stelle heißt es dann wieder FEHLER!!!

 

Anbei ein Minibeispiel um das explizite Speichern darzustellen.

 

Großes DANKESCHÖN für den Aufwand!!!
Das ist dann für die Alternative mit den gebundenen Feldern oder? Ich werde es gleich mal ausprobieren in meinem Formular *wink.gif*

 

Hallo FelySN89!

Code:

Gibt es in der Tabelle tblAnsprechpartnerTEST mehrere Autowerte?
Welche ID.. ist den nun die eigentliche ID dieser Tabelle? Alle übrigen IDs können doch nur Fremdschlüssel sein.

Ferner:
1. Die ID einer Tabelle, so ein Autowert, ist immer eine Zahl, sie darf man beim Speichern nach AddNew gar nicht angeben.
2. Die Definition Code:

bewirkt, daß nur strMitarbeiter als String definiert ist, alle davor liegenden Variablen sind dann vom Typ Variant. Du mußt "As String" bei jeder Variablen anführen.
3. Warum Sind die IDs strID, strID_N, strID_AN dann nicht als Zahl definiert?

Wolfgang

 

Ja, das ist ein gebundenes Formular mit gebundenen Feldern.
Das ist m.E. für die Anforderung keine Alternative sondern die richtige/einfache Lösung

 

\@Wolfgang/wb_3001: In der Tabelle gibt es nur einen Autowert und zwar ID_AN. Die ID und ID_N sind Fremdschlüssel und nur dazu da, um die Datensätze mit anderen Tabellen vernküpfen zu können.
Die Variablendeklaration erfolgt bei mir eher willkürlich was den Daten-/Variablentyp angeht, da ich größtenteils nicht nachvollziehen kann, welchen Typ man für was einsetzt und mit String bin ich bisher gut gefahren *wink.gif* Ich habe bisher noch keine Seite gefunden, bei der die Unterschiede bzw Einsatzzwecke der Variablentypen nachvollziehbar erklärt sind... oder sind die Unterschiede wirklich so marginal?!

Es geht ja auch nicht darum einen neuen Datensatz zu erstellen, sondern einen vorhandenen zu bearbeiten und die ID_AN beizubehalten. die Prozedur zum sichern hatte ich so aus meinem Formular übernommen

Bist du dir sicher, dass nur die letzte Variable als String deklariert wird? Das kenne ich selbst so noch aus der Schule, dass man mehrere Varaiblen, die dem gleichen Typ entsprechen sollen, einfach so auflisten kann bei der Deklaration...?! Aber ich lasse mich da gerne eines besseren belehren...

 

Dann haben sie Dir in der Schule was falsches vermittelt; in VBA wird über die obige Notation nur die letzte Variable "getypt". Alle anderen sind "ungetypt" und werden daher als Variant verwendet.

Das solltest Du ändern... das ist Basiswissen was nötig ist wenn Du mit VBA arbeiten möchtest.

Klappt mein Beispiel nicht da Du jetzt weiter auf dem ungebundene "Gedöns" rumreitest?

 

\@CptChaos: Die Nachfrage war rein interessehalber, bin eigentlich darauf aus, die gebundene Variante zu nutzen *wink.gif*

Okay wieder was dazu gelernt und festgestellt, dass ich noch viel zu lernen habe^^
Bin gerade erst dazu gekommen, dein Beispiel bei mir umzusetzen. Ich probiere aber noch ein wenig in deinem Beispiel rum. So kam die MsgBox ja beim Drücken der ENTER-Taste, ist schon gut so, bloß will ich das ja auch bei Klick auf den SPEICHERN-Button im Formular...

Kann ich diesen Code nicht auch einfach in Private Sub cmdSpeichern_Click() übernehmen? Code:

Und beim Private Sub cmdAbbrechen_Click() dürfte es doch reichen wenn ich Code:

nutze und das Formular schließe oder geht das nicht so einfach?

 

Me.Undo setzt die Änderungen zurück.
Me.Dirty prüft ob Änderungen statt gefunden haben
Me.Dirty = False speichert die Änderungen.

Wenn Du diese Prüfung auch an anderer Stelle benötigst, solltest Du die Funktion "kapseln" und von den beiden Stellen aufrufen...

Probier doch mal und zeige das Testergebnis hier als Beispiel

 

Hallo FelySN89!

Das ist kein wirklich gutes Argument.
Aus Tabellenfeldern den Variablentyp zu ermitteln ist doch einfach!
Bei Vergleichsoperationen für Zahlenwerte Strings zu verwenden ist immer ein Sakrileg.

Aber Dein ursprünglicher Code
Code:

fügte doch einen neuen Datensatz hinzu!

Egal. Du hast Dich nun für ein gebundenes Formular entschieden.
Ich bin nicht so dogmatisch wie CptChaos, was ungebundene Forms betrifft.

Und "Ja", zu Deinem Code, die Bearbeitung abzubrechen.

Noch eine Frage:
Code:

Hat die Tabelle tblAnsprechpartnerTEST neben ID_AN nur e i n weiteres Feld Anrede, in welches Du alle Daten sequentiell aneinanderfügst?
Selbst beim Testen solltest Du praxisnahe agieren. Aus einer vorhandenen Tabelle eine Testtabelle zu erstellen ist kein Jahrhundertprojekt.

Wolfgang