Office: (Office 2007) Neuer Datensatz in Ufo des Navigationsformular

Bei Anlage des UF hat der UF-Assistent die beiden verbindenden Felder abgefragt und eingestellt. Jetzt stehen diese Felder dort im UF-Objekt unter verknüpfen von / nach. Das hatte ich mit Filter gemeint, sorry.

Darüberhinaus gibt es keinen Filter. Es kann also sein, dass die Query (Datenherkunft) selbst keine Daten liefert oder durch die 'Verknüpfung zum HF-Satz' keine Daten geliefert werden - was aber nach meinen Tests keinen sichtbaren Unterschied macht.

Habe jetzt festgestellt: Die Meldung tritt in zwei Konstellationen auf:
a) wenn ich im HF auf einen Satz navigiert habe, der im UF keine Daten hat - und ich dann im UF den Aktionsbutton 'Neuanlage' betätige
b) wenn ich um UF alle vorhandenen Sätze gelöscht habe und dann im HF auf einen anderen Satz blättere.

Habe zu b) ganz aktuell noch eine evtl. fehlerhafte Programmierung im UF festgestellt. Das muss ich aber noch überprüfen, ich melde mich danach nochmal.

 

Hallo VRAccFan,

O.K., verständlich. War eher so Quick & Dirty.
Andere Idee; - kann es sein, dass da im UFo schon ein
(neuer) DS offen ist. Das wäre IMO das natürliche Ver-
halten von leeren UFos. Da kannst Du dann per VBA
keinen neuen DS anlegen, per Navibutton aber schon.
Diese Vermutung stützt sich auch auf dies

Prüfe mal .NewRecord beim Entern.
hth
gruss ekkehard

 

Warum einfach, wenn es umständlich geht.

Ein Datensatz wird in einer Tabelle gespeichert. Eine Anfügeabfrage wäre der direkte und einfache Weg und könnte nur scheitern, wenn ein eindeutiger Index oder evtl. vorhandene Beziehungen dem entgegen stehen.
Man wäre aber in jedem Fall unabhängig von Formularabhängigkeiten, Formularzuständen, Fokusstand und DoCmd-Getue.

Hier setzt sich sehr wahrscheinlich der umständliche Weg fort.
acSave speichert dann wohl nicht den Datensatz, sondern das Formular, das nicht in der Entwurfsansicht ist und wo es somit nichts zu speichern gibt.

 

Hallo zusammen,

ich habe das Hinzufügen auf eine Query umgestellt, das Resultat ist aber immer noch dasselbe. Die Meldung tritt auf wenn sich an der gesamten Datenmenge für das UF (alle UF-Seiten) seit FormOpen etwas geändert hat und das UF mit leeren Daten arbeiten soll.

Unter 'Office-Lösung' (weitere Suchbegriffe = HansHans + Unterformular) fand ich die selbe Situation beschrieben und habe dort auch geantwortet.

Eine 'Vermeidungsstrategie' (?) scheint es zu geben: Im UF 'Hinzufügen = Ja' setzen, dann tritt die Fehlermeldung (der Fehler?) nicht mehr auf.

Danke an alle von VRAccFan - mit leichten Schrammen *frown.gif*

 

In nicht wenigen Fällen ist es sinnvoll, den verwendeten Code vollständig zu zeigen und nicht nur eine Beschreibung darüber abzuliefern.

Ich hätte keine Vorstellung, welche Fehlermeldung ein Form-Requery liefern sollte, wenn nicht zusätzliche Codes ihre Wirkung entfalten.

 

Daie Meldung tritt hochwahrscheinlich in einem Ereignis auf, zu dem ich gar keinen Code habe (z.B. beim Blättern im HF, beim Lesen der UF-Datenquelle mit Verknüpfung zu HF). Eigener Code ist zum Beispiel:

Code:

Aber hier trat der Fehler nie auf (mit Debug-Haltepunkten festgestellt).

Wenn jetzt der "Workaround" funzt, soll es mir ja recht sein.

 

Eine wirkliche Aussagekraft haben diese Zeilen für mich nicht, und das ungenannte kann etliche Fehlerquellen beherbergen:
- HFo- oder UFo-Code?
- Was trägt die Abfrage ein? Woher kommen die Werte? Wird überhaupt real ein Datensatz angefügt? Bei einem leeren UFo, wo das Anfügen eines neuen Datensatzes misslingt, dürfte das Springen auf den letzten Datensatz schwierig werden.

Das DoCmd.Openquery (aus Makro erzeugter "VBA-Code") ist da nur eine unschöne Begleiterscheinung.

 

Hallo Ebs17, hier sende ich dir noch weitere Infos.

Der gepostete Code wird im UFO ausgeführt - bei Klick im Button des UFO-Formularfußes.

Die Abfrage erzeugt genau einen Datensatz für das UFO.

Sie stammen aus der Datenbank und zwar genau aus dem Datensatz, der im HFO aktuell angezeigt wird (die ID aus HFO ist Kriterium in der Anfüge-Query). Fachlich ist das eine Kopie des HFO-Satzes - mit minimalen Abweichungen.

Ja, auf jeden Fall wird ein Satz angefügt und anschließend im UFO (nach der Fehlermeldung) auch korrekt angezeigt. Deshalb ist auch das acLast ok, die neue ID wird in einer nachfolgenden Aktion (ebenfalls Query) benötigt. Dieses acLast führt ja auch nicht zu dieser Meldung, sondern irgend ein anderes Ereignis.

Ich würde jetzt auf weitere Analysen oder Mutmaßungen verzichten und die Sache als gegeben nehmen. Da die Meldung aber bei Anfügen=Ja nicht erscheint, wüsste ich nicht, wie diese Sachverhalte zur Fehlermeldung beitragen sollten. Aber man weiß ja: Nichts ist unmöglich. Wenn es doch einleuchtende Erklärungen gäbe - umso besser.

Vielen Dank. VRAccFan.

 

Ereignisse geben keine Meldungen ab und erzeugen keine Fehler, Ereignisprozeduren durchaus.
Dafür sind Ereignisse immer da, Ereignisprozeduren nur, wenn sie angelegt wurden.