Filtern UFO1 nach UFO2

Hallo Leute,

ich habe wieder mal ein Problem, ich habe in einem Hauptformular 2 ungebundene Unterformulare enthalten, die die selbe Datensatzherkunft besitzen.
Auf dem HFO befindet sich nun ein ungebundenes Textfeld mit dem Feldinhalt =[UFO1].[Formular]![FN] , dessen Sichtbarkeit auf nein steht (also rein um die aktuelle FN zwischen zu speichern).

Nun möchte ich, dass wenn ich in dem UFO1 (Endlosformular) auf ein Feld klicke bzw ein Feld davon den Fokus hat dann das UFO2 (Detailansicht) gefiltert wird bzw zum selben Datensatz gesprungen wird, wo dann FN von UFO2 gleich der FN vom UFO1 ist.
Und wenn ich mittels nachgebauten Reitern die SourceObject Eigenschaft von UFO2 ändere dann dort auch wieder der Filter angewendet wird bzw. der Datensatz gesucht wird.

MfG
Philipp K.

Ok ich habe das Problem nun selbst beseitig, durch einen doch recht simplen Code den ich im Internet gefunden habe.

Damit das Detailfenster nicht immer zum 1. Datensatz zurückspringt, wenn man die Reiter benutzt hinterlegt man folgenden Code bei dem „Laden“- Ereignis des Hauptformulares und bei den Reitern.

Set Me.Detailformular.Form.Recordset = Me.Endlosformular.Form.Recordset

ich hoffe ich konnte damit anderen mit dem selben oder ähnlichem Problem helfen.

MfG
Philipp K.

Hallo,
reichlioch verbogene Konstruktion… mit latentem Risiko zu einem Datenchaos.

ich habe wieder mal ein Problem, ich habe in einem
Hauptformular 2 ungebundene Unterformulare enthalten, die die
selbe Datensatzherkunft besitzen.

Widerspruch in sich: Wenn die Forms eine Datenherkunft besitzen, dann sind sie auch gebunden…

Auf dem HFO befindet sich nun ein ungebundenes Textfeld mit
dem Feldinhalt =[UFO1].[Formular]![FN] , dessen Sichtbarkeit
auf nein steht (also rein um die aktuelle FN zwischen zu
speichern)

–> das Feld ist m. E. überflüssig

Nun möchte ich, dass wenn ich in dem UFO1 (Endlosformular) auf
ein Feld klicke bzw ein Feld davon den Fokus hat dann das UFO2
(Detailansicht) gefiltert wird bzw zum selben Datensatz
gesprungen wird, wo dann FN von UFO2 gleich der FN vom UFO1
ist.

im Unterform1:

Sub Fn_DblClick()
Me.Parent!UFO2.Form.Recordsource=" select * from tblgemeinsameTabelle where FN=" & Me!FN
End Sub

Und wenn ich mittels nachgebauten Reitern die SourceObject
Eigenschaft von UFO2 ändere dann dort auch wieder der Filter
angewendet wird bzw. der Datensatz gesucht wird.

dito, nur beim Change-Ereignis des Reg.-St.-Elementes.

Viele Grüße vom Bodensee
Franz , DF6GL

PS: Feedback erwünscht!

Hallo,

Du begibst Dich auf ziemlich dünnes Eis…

Welchen Sinn hat es denn, ein zweites UFO mit genau denselben DS anzuzeigen? Außerdem handelt man sich unvorhergesehene Datensatzsperrungen ein.

Viele Grüße vom Bodensee
Franz , DF6GL

PS: Feedback erwünscht!

Hi Franz,

das Endlosformular ist oben und das Detailformular unten. Ich habe auch die Felder vom Endlosformular gesperrt, so dass man dort nichts verändern kann. Wieso sollte ich nicht die selbe Datensatzherkunft benutzen, wenn ich im Endlosform alle Firmen z.B. anzeigen lasse und darunter die Detailinformationen zur ausgewählten Firma?

Außerdem ist das mit den Datensatzsperrungen ja gar nicht vorhanden, weil der Fokus ja nicht auf beiden gleichzeitig liegt oder liegen kann.

Zum Thema dünnes Eis: Ich habe die Datebank schon gut so hinbekommen, dass alles funktioniert ohne irgendwelche Dateninkonsistenz, da besteht keine Sorge. Ich hab es allerdings nun umgeändert, dass keine 6 Ebenen von Unterformularen mehr ineinander sind, weil das zu unübersichtlich ist für den normalen User und dann nun mehr mit Popup-Formularen gearbeitet. Ziel ist ein eigenes Programm mittels DevKit daraus zu machen, dass alle Unternehmensprozesse etc. in sich abbildet.

MfG
Philipp K.

Hi,

naja, dazu könnte ich einen Roman schreiben…will aber nur kurz anmerken:

das Endlosformular ist oben und das Detailformular unten.

??? Wo unten, bzw. oben?

Ich habe auch die Felder vom Endlosformular gesperrt, so dass man
dort nichts verändern kann. Wieso sollte ich nicht die selbe
Datensatzherkunft benutzen, wenn ich im Endlosform alle Firmen
z.B. anzeigen lasse und darunter die Detailinformationen zur
ausgewählten Firma?

allein das läßt auf eine ungenügende Tabellenstruktur schliessen, die früher oder später Schlaglöcher bekommt.

Außerdem ist das mit den Datensatzsperrungen ja gar nicht
vorhanden, weil der Fokus ja nicht auf beiden gleichzeitig
liegt oder liegen kann.

das ist schlicht und ergreifend falsch.

Zum Thema dünnes Eis: Ich habe die Datebank schon gut so
hinbekommen, dass alles funktioniert ohne irgendwelche
Dateninkonsistenz, da besteht keine Sorge.

ok, wenn es geht, soll es ja recht sein. Ich würde das aber nach meiner (oberflächlichen) Kenntnislage der DB nicht unterschreiben wollen.

Ich hab es allerdings nun umgeändert, dass keine 6 Ebenen

??? Ich hoffe, es ist nicht so, wie sich das jetzt anhört…

von Unterformularen mehr ineinander sind, weil das zu
unübersichtlich ist für den normalen User und dann nun mehr
mit Popup-Formularen gearbeitet.

egal, ob Unterforms oder separate Popup-Forms

Ziel ist ein eigenes Programm
mittels DevKit daraus zu machen,

Was ist ein „eigenes Programm“ ? Wenn das eine Exe-Datei (selbstständig ablaufend) werden soll, dann ist das gar nicht möglich. Für eine MDB/MDE-Datei wird IMMER Access gebraucht, auch wenn es sich um eine Runtime-Version handeln sollte, die nichts anderes als ein abgespecktes Access ist.

dass alle
Unternehmensprozesse etc. in sich abbildet.

kann man schon abbilden, aber dazu braucht es (sehr viel) mehr als ein oder zwei Tabellen…

Das soll alles keine Kritik sein, nur gutgemeinte Hinweise auf mögliche Betonwände, gegen die Du evtl. fahren wirst.

Viele Grüße vom Bodensee
Franz , DF6GL

PS: Feedback erwünscht!