Office: (Office 2016) Unterformular aktualisieren

Hallo zusammen,

vielleicht kann mir hier jemand bei meiner "Verständnisfrage" helfen

ich verändere "dynamische" die Datenquelle des UFOs eines Formulars:

Bsp auf Form_Current:

PHP:

         strSQL = "SELECT DM01_REMARKS.IDREMARK, DM01_REMARKS.OPPID, DM01_REMARKS.INSERT_DATE, DM01_REMARKS.REMARKTXT"
strSQL = strSQL & " FROM DM01_REMARKS"
strSQL = strSQL & " WHERE ((DM01_REMARKS.OPPID)=" & Me.IDOPP & ")"
strSQL = strSQL & " ORDER BY DM01_REMARKS.INSERT_DATE DESC;"

Set QD = DB.QueryDefs("qryRemarks")
QD.SQL = strSQL
QD.Close


:)

 

...und der lautet bitte....?

 

Hallo TNP,

wie Elmar schon gefragt hat, gibt deine Fehlerbeschreibung nicht viel her.

zu deinem Verständnis:
Um ein UFO zu aktualisieren, reicht normalerweise eine .Requery(). Du aber änderst die unterliegende Querydef. Da ein Formular mit einer eigenen internen Datenstruktur arbeitet und die Initialisierung schon abgeschlossen ist, bekommt das Formular davon gar nichts mit. Erst durch die Neuzuweisung der Recordsource-Eigenschaft werden diese Datenstrukturen neu initialisiert.

Was die Referenzierung der Recordsource-Eigenschaft des UFOs betrifft:
Forms: Refer to Form and Subform properties and controls
Da ist dir sicherlich ein Fehler unterlaufen.

Hiermit
Code:

sprichst du die Standard-Instanz der entsprechenden Form-Klasse an, nicht aber die aktuelle Klasseninstanz!
Die Standart-Instanz sollte man eigentlich nicht verwenden.

Aber mal etwas ganz anderes. Dieser Code wird hoffentlich nicht in einer produktiven Umgebung eingesetzt. In einem Form-Current Event ständig die SQL-Source einer permanenten Query zu ändern, um die Where-Bedingung eines UFOs anzupassen, ist absolut kontraproduktiv. Wenn das notwendig ist, sollte man das Design überdenken und sich mit den Grundlagen von Access und speziell nochmal mit den Unterformularen befassen.

UFOs werden mit dem HF normalerweise über LinkFields verknüpft. Damit entfällt so eine Programmierung komplett und die Synchronisierung von HF und UFO wird von Access selbst übernommen.

Unabhängig davon führt diese Art der Programmierung mit der ständigen Neudefinition der Querydef zum Aufblähen der Datenbank. Das führt letztendlich dazu, daß die DB regelmäßg komprimiert werden muß, mit all den Unzulänglichkeiten, die dabei auftreten können.

Gruß Ulrich

 

... 2455

 

Hallo,

im ersten Beitrag steht Projekt manchmal mit "c" und manchmal mit "k". Vielleicht solltest du mal alle Formulare, Steuerelemente, Datenherkünfte und VBA-Codes darauf überprüfen.

Außerdem, wenn sich durch die Änderung des SQL-Codes andere Tabellen-/Abfragefelder ergeben, müsste das auch in den jeweiligen Steuerelementinhalten der UFO-Steuerelemente geschehen.

Einfacher wäre UFO-Formularwechsel wie folgt:
donkarls Access-Seiten

 

danke schon mal für's genau hinsehen... leider habe ich denTippfehler nur hier im Beitrag gemacht.

Trotzdem habe ich den Rahmen für das UFO nun einfach mal (mehrfach) umbenannt (um Tippfehler, Doppelungen etc. auszuschließen) - kein Erfolg.

Ein Phänomen konnte ich allerdings dabei beobachten. Wenn ich bei geöffneten Formularen das Steuerelement für das UFO umbenenne, dann alle stelle Hintergrund (VBA) gerade ziehen, wo diese Bennungen auftaucht, lädt das Formular samt UFO genau einmal sauber durch. Wenn ich die Formulare schließen und neu öffne -> 2455

Kann mir der Focus irgendwohin rutschen und das Phänomen auslösen?

Ansonsten bekommt das Hauptform beim Form_Load ein RecordSetClone als RS (vorher auch ungebunden - wie das UFO - was LinkedFields neben vielen anderen Performancegründen für mich ausschließt... aber egal). Kann hieraus irgendwas resultieren?

 

Hallo TNP,

Da muß ein Fehler vorliegen, sonst würde nicht der Fehler 2455 kommen! Benenne die Steuerelemente und Formulare mit einem Prefix. Es gibt verschiedene Namenskonventionen, aber ich z.B. verwende für Formulare "frm..." und für Formulare, die nur als Unterformulare dienen, "sfrm...". Ein SubForm-Control bekommt bei mir das Prefix "sub..." oder einfach "subForm" oder "subContainer", wenn es in einem Formular nur einmal vorhanden ist - nur ein Vorschlag. Danach sollte dich Intellisense bei der Auswah der Steuerelemente und deren Eigenschaften unterstützen können. Übrigens: für die Referenzierung eines Unterformulars wird dessen Name nicht verwendet, sondern nur der Name des SubForm-Controls.

Das hört sich für mich sehr abstruse an. Es kann Gründe geben, Formulare dynamisch an neue Datensatzquellen zu binden, mach ich auch - aber nicht so - und man kann trotzdem noch mit LinkedFields arbeiten.

Vielleicht läds du mal ein Beispiel hier hoch.

Gruß Ulrich

 

Änderung xxxx und es liegt wohl am Recordset des HF (das im Dialog geöffnet wird).

Ich weise dem HF nämlich nicht ein RSClone sondern hart das RS des aufrufenden Formulars zu. Mit dem Clone funktioniert später alles im UFO einwandfrei. Wenn ich wieder auf des RS wechsle -> 2455.

 

Hallo Ulrich,

ist soweit bekannt... nach > 15 Jahren schleicht sich bei sauberen Benennungen aber manchmal der Schlendrian ein...
Und wie hoffentlich halbwegs rüber gebracht: ja - ich habe natürlich den Namen des SubForm-Controls benutzt.

Was ist abstrus daran ein Formular (dessen Recordset) an das Recordset eines anderen Formulars zu binden?
Das Access(FrontEnd) muss leider auch über WLAN mit einem SQL BackEnd (nicht gerade klein) arbeiten. Da wir nur die nötigsten (LookUp-)Tabellen auch lokal ziehen wollen, muss halt viel "recycelt" werden, bevor es wieder durch den Draht (oder nicht viel schlimmer - Luft) geht.

Wie ist denn dein Ansatz, wenn es darum geht Datensatzquellen "dynamisch" zu setzen?

Vielleicht hat sich das Verhalten von Access hier auch über die Jahre geändert, aber gerade bei der Vorgehensweise mit LinkedFields geht (oder ging - seit 7-8 Jahren nicht mehr geguckt) mir zuviel Traffic durchs Netz.

Ganz davon ab, dass es bei mir mit ungebunden Formularen Stress macht.

Gruß
TNP

 

Gespeicherte Abfrage ändern, LinkedFields, Recordset klonen ... das alles sind verschiedene Dinge und werden hier irgendwie zusammenhangslos zusammengewürfelt, unter dem Glauben, man wüsste, wovon man redet.
Ich habe da einen anderen Eindruck.

Zum allerersten Code: Da wird die Definition einer gespeicherten Abfrage geändert. Ein Formular wird davon nicht berührt, nicht mal, wenn die Abfrage die Datenherkunft des Formulars ist.
Da müsste nämlich nach der Maßnahme ein Requery ausgeführt werden.
Code:

... würde das Gleiche erledigen in einer deutlich übersichtlicheren Form.

Der geglaubte Vorteil einer gespeicherten Abfrage gegenüber der SQL-Anweisung würde erst nach der ersten Ausführung der Abfrage greifen, wenn dann auch der Abfrageplan erstellt wurde. Die "Dynamik" unterläuft das aber.

 

;-), ja - danke.

 

Hallo TNP,

ich habe ja nur angemerkt...

Alles. Dasselbe Recordset in zwei Formularen zu verwenden, die jeweils intern eigene Datenstrukturen aufbauen, ist keine gute Idee und muß schiefgehen. Wofür soll das überhaupt gut sein?

Wenn du Probleme mit deinem "Draht" hast, was auch heute noch im Zuge von Highspeed Internet vorkommt, kannst du die UFOs zunächst ohne Recordsource oder mit einer Recordsource laden, die keine DS liefert. Anschließend wird beim "Binden" die Recordsource angepaßt und die Controlsource der Steuerelemente sowie die LinkFields richtig eingestellt. Damit läßt sich der Traffic schon ein bißchen reduzieren.
Zudem bietet es sich an, den Lokalen Cache zu vergrößern und gelegentlich gezielt zu bereinigen.

Gruß Ulrich

 

Ich versuche mal auf die Essenz des Problems zu reduzieren.

Ich rufe ein ungebundenes Formular (mit eingebettetem ungebundenen UFO) auf.

Das RecordSET des Hauptformulars befülle ich mit dem RecordSet des aufrufenden Forms (und hier kann ich reproduzierbar das Problem erzeugen - deswegen die laienhafte und zusammenhanglose Aneinanderreihung der Begriffe Recordset, Recordsouce, gespeicherte Abfrage etc. - LinkedFields stammt nicht von mir)

Die Datensatzherkunft des UFO ist eine "gepeicherte Abfrage", die wie oben beschrieben im gleichen Zuge geändert wird.
Würde ich versuchen die Recordsource direkt mit dem Select zu befüllen käme hier übrigens auch schon die Fehlermeldung.
Das Problem ist nämlich, dass ich genau an dieser Stelle nicht mehr an die Recordsource-Eigenschaft komme(das ist allerdings nicht mein Grund für den Umweg über die Abfrage... es lief ja vorher schon mal ein paar Jahre).

Mittlerweile habe ich ein paar Änderungen zurückentwickelt und eine Änderung der letzten Tage war, dass das HF nicht mittels RSClone, sondern direkt dem RS befüllt wird. Genau hierdurch ensteht mein Phänomen. Wenn ich das HF wieder mit einem RecordsetClone befülle kann ich die Recordsource-Eigenschaft des UFO ansprechen.

Und an dem Punkt endet mein Latein.

Ich bin natürlich auch für alle Hinweise dankbar, wie unschön meine Vorgehensweise ist(auch ohne die Gründe dafür zu kennen), aber wirklich interessiert wäre an einem Grund für das beschriebene Phänomen

 

nabend knobbi38,

Beide Formular verarbeiten 1:1 die gleichen Daten/Felder. Das Erste ist nur ein tabellarischer Überblick. Von hier springt man in ein grafisch aufgehübschtes Formular (mit eben dem UFO) ab, dass zwar nur einen Datensatz genauer zeigt, man aber durch die anderen "scrollen" kann. Da ich jede Änderung gerne sofort in dem tabellarischen AbsprungForm hätte, der gewählte Weg.

Unser Performancekiller ist an der Stelle das WLAN.

gruß
TNP

 

Hallo TNP,

vielleicht sollten wir mal eins nach dem anderen abklären:

Das ist grundsätzlich FALSCH! Was soll das bewirken? Jedes Formular braucht ein eigenständiges Recordset, wenn es gebunden sein soll. Wenn es gebunden sein soll, kann das HF auch direkt mit einer gültigen Recordsource geöffnet werden, denn früher oder später müssen die Daten ja geladen werden. Ungebundenes Öffnen und dann später eine Datenquelle zuzuweisen, bringt keinen Vorteil.
Was man machen kann ist, daß Unterformular noch gar nicht zu laden, weder ungebunden noch gebunden. Normalerweise läd Access erst immer das UFO und dann das HF.

Gruß Ulrich