Office: (Office 2010) Einstellungen für Kombinationsfelder falsch gesetzt?

Habe meine Ansprüche doch zurückgeschraubt.
Nach erfolgreichem Abspeichern cleare setzte ich die Kundennummer ComboBox doch einfach stupide auf null und lass den Anwender die (nun neu angelegte) Nummer noch einmal eintippen.

Hilft #29?
Ich hab die starke Vermutung es hat was mit dem Abspeichern zutun.
Irgendwie muss ich die Tabelle erst richtig "hart speichern" und das Form nochmal neu aufmachen (/requery).

Versuche mich gerade an Code:

jedoch müsste ich sie zum abspeichern erstmal öffnen.
Nicht sicher ob das der richtige Weg ist.

Ich bilde mir gerade ein die SQL Query haut mir die neue Kundennummer brav da rein, aber das Haupt GUI arbeitet noch mit der alten Version der Tabelle und findet die neu angelegte Nummer dementsprechend nicht (nie).

 

Nein, das ist Schrott. Entweder du nimmst verd... noch mal das gebundene Formular oder du programmierst die Anwendung so, dass deine User nicht darunter leiden müssen.
Nach einem INSERT ist der neue Datensatz in der Tabelle. Save acTable speichert nur den Tabellenentwurf, keine Datensätze.

Wie bringst du denn deine Daten in das Form mit den Kombis? Liest du die aus irgendwelchen Recordsets zur Laufzeit ein? Da liegt möglicherweise der Hase im Pfeffer, ein Requery funktioniert nur mit gebundenen Objekten.

maike

 

Hi,

es ist schade um das eigentlich interessante Thema, dass du den Thread hier in den letzten Stunden dermaßen zugetextet hast. Wer soll das noch alles lesen und beantworten?!
Daher greife ich hier jetzt nur mal die wichtigsten Punkte heraus...

Das ist Blödsinn und es ist völlig ohne Belang, wie die Spaltenbreiten gezählt werden.

Es ist ein grober Fehler, mit unterschiedlichen RowSource-Einstellungen zu arbeiten. Klar dass du damit durcheinander kommst.

Genau so ist es und ich dachte das hätte ich bereits vor längerem so vorgeschlagen.

Das ist ein ziemlicher Unfug, statt dessen solltest du das NotInList-Ereignis RICHTIG nutzen. Code:

Das ganze Geheimnis liegt in der richtigen Wahl des Rückgabewertes.

 

- den von dir im Code rot markierten Bereich habe ich von hier übernommen. Nehme ich ihn raus, so bekomme ich beim Öffnen des Forms zum Anlegen eines neuen Users noch eine Meldung hinterhergeworfen die mir sagt ich habe einen Wert im Kundennummernfeld eingegeben der nicht in der Liste ist.
- leider sehe ich keinen Rückgabewert in NotInList. Ferner dachte ich nur Funktionen können solche haben.
- die MS Doku schreibt weiter unten

was ja auch maike schon gesagt hat. Dies führt zwar korrekt zur Lösung meines Problems das neu angelegte Kundennummern direkt verfügbar sind. Ich versuche gerade nur hinzukriegen das man beim "Zurückkommen zum alten Fenster" nicht nur die neue Kundennummer eingeben kann, sondern sie sogar schon für einen eingegeben ist.

Wenn ich euch zu hart auf den Keks gehe, dann ignoriert meien Posts und Threads bitte einfach. Ich finde es toll hier auf so schnell und viel Feedback zu kommen. Das ich mit meinen Kenntnissen hier ne Menge Müll aufbringe möchte ich nicht abstreiten, jedoch brauchts bei mir anscheinend immer ne Weile bis ich verstehe wovon ihr redet. Gerne würde ich den Vorschlag der gebundenen Formulare für den Moment vernachlässigen, da ich mich freuen würde erst einmal das momentan verfolge Herangehen zu einem produktiven Ende zu bringen. Mein Lerneffekt hält sich in Grenzen wenn ich alle 2 Meter umdrehen und einen anderen Weg einschalgen darf.

No offense.

 

Liebe Anne, ich widerspreche dir ja nur ungern, vor allem nicht, wenn du recht hast wie bei der Zählung der Spaltenbreiten *Smilie - aber

ist da imho korrekt, da die Eingabe des weiteren über ein Formular erfolgt.

Problem ist die fehlende Kenntnis der neuen KundenID im (ungebundenen) Eingabe-Formular. Somit kann diese nicht an das Kombi weitergegeben und der neue Kunde direkt angezeigt werden.

maike

 

Ich sage mal folgendes:
Wenn du es geschafft hast, von deinem ungebundenen Formular aus oder wie auch sonst immer die neue ID herauszufinden und an das Kombi bzw. das Ursprungsformular weiterzureichen,
dann lese ich wieder mit.
Wie du ja weißt, mach ich mir nicht gern einen Kopf über komplizierte Dinge, die auch einfach zu erledigen sind *wink.gif* .
maike

 

Code:

/fixed.
Danke für die Hilfe.

 

Ähh, arbeitet dein Code das so nacheinander ab?
Code:

filtert auf KN, dürfte also nur noch ein Datensatz sein
Code:

setzt auf welchen Wert und warum?
Code:

überflüssig, weil RowSource gesetzt wurde
Code:

schmeißt den gerade gesetzten Filter wieder raus
*confused.gif*
maike

 

Scheinbar. Es macht jedenfalls exakt das was ich wollte.

filtert auf KN, dürfte also nur noch ein Datensatz sein

Korrekt. Was auch grundlage für die nächste Zeile ist.

setzt auf welchen Wert und warum?

ItemData(0) scheint der erste Eintrag in der Liste zu sein. Die (Liste) widerum wurde ja gerade mittels Rowsource auf den einen interessanten Eintrag reduziert, so dass es mir genau das in die ComboBox schreibt was ich will.

überflüssig, weil RowSource gesetzt wurde

Thx

schmeißt den gerade gesetzten Filter wieder raus

Der Filter greift ja sogesehen nur auf das was man sieht wenn man das Dropdownmenü öffnet. Und das soll ja nicht gefiltert sein.
Vermutlich ein unbeabsichtiger Nebeneffekt von ComboBoxen: Es löscht hierdurch nicht den sichtbaren Inhalt/Selektion raus. Und dieses "Nebenprodukt" ist ja zufällig mein eigentliches Ziel gewesen.

 

*sos
maike

 

\@Maike:

ist da imho korrekt, da die Eingabe des weiteren über ein Formular erfolgt.

Nein, da irrst du. In diesem Fall muss acDataErrAdded genommen werden, denn das bewirkt, dass Access eigenständig das Kombifeld aktualisiert. Damit das funktioniert, muss das Eingabeformular natürlich modal, d.h. im Dialogmodus, geöffnet werden.

...und die letzte Eingabe wird auch automatisch angezeigt, man muss die neu vergebene ID also nicht kennen!

 

Zu früh gefreut.
Er legt einem den Datensatz der neuen Kundennummer zwar an und gibt diese auch wunderbar an das vorherige Fenster zurück, jedoch bleibt das Problem das er die neusten Einträge alle nur akzeptiert wenn man sie über das Dropdownmenü direkt auswählt.
- ich lege Kundennummer 999 an
- er legt es an, bringt mich zurück ins Haupt GUI, ich kann den gesamten Antrag speichern
- gehe ich erneut in ein frisches Haupt GUI um unter der jetzt korrekt existierenden Kundennummer 999 einen anderen Antrag anzulegen und gebe "999" als Kundennummer ein, so triggert er NotInList
- öffne ich das Dropdown und wähle 999 manuel aus, so funktionierts wunderbar

Glaubt ihr der Fehler käme nicht zustande, würde ich den Weg der gebundenen Formulare gehen?
Würde es dann noch einmal von vorne machen und die heutige Arbeit verwerfen, sofern das mehr Erfolg in Aussicht hat.

 

Schade, dann ist die viel geschätzte Access-FAQ an der Stelle leider unvollständig.

Von rausnehmen war ja auch keine Rede, sonder von der "richtigen Wahl" der Access-Konstanten.

Viele Ereignisprozeduren arbeiten mit Parametern, so neu dürfte das nicht sein.

Ja, aber weiter oben wird der Verwendungszweck von acDataErrAdded beschrieben.

Wie gesagt, das erledigt unter den oben beschriebenen Voraussetzungen Access für dich.

Keine Sorge, man greift nur manchmal zu deutlicheren Worten, wenn man sich nicht verstanden fühlt. *wink.gif*

Auf das NotInList-Ereignis machte ich bereits in Beitrag #4 aufmerksam und das ist mAn hier die einzig sinnvolle Vorgehensweise.

dito.

 

Dann zeige doch bitte den aktuellen Stand deines Codes.

 

Ja, aber weiter oben wird der Verwendungszweck von acDataErrAdded beschrieben.

nutze ich acDataErrAdded, so bekomme ich zwischen dem "Yes"-Drücken und dem Öffnen des NeuenKundeEingabeformulars erneut einen Hinweis das ich Inhalte in Felder eingebe die nicht ok sind.

Dann zeige doch bitte den aktuellen Stand deines Codes.

Nevermind. Funktioniert (momentan) doch.
Fehler lag (erneut) an einem leeren Datensatz in der Tabelle. Wo der herkam weiss ich nicht, löscht man ihn jedoch raus, so funktioniert es wunderbar.