Access-o-Mania

Hallo zusammen,

ich versuche krampfhaft, die ID eines fokussierten Datensatzes eines Auswahl-Ufos
in einem 2. Ufo, welche die Tabelle Werte beinhaltet zu speichern.

Der Versuch mit den Ereignissen Beim Anzeigen, Vor oder Nach Aktualisierung,
Bei geändert im Auswahl-Ufo schlug fehl. Dort wollte ich den Code setzen:

    Forms!HFO!Werte-UFO.Form!ID = Me![ID_akt]
    Me!Werte_UFO.Form.Requery

Setzte ich den Code auf eine Befehlsschaltfläche, funktioniert er.

Ich habe mich auch schon gefragt, ob es evtl. mit einem Listenfeld nicht besser geht?
Außerdem ändert sich u.U.der Fokus im Ufo, wenn andere Formulare oder Befehle aufgerufen werden.

Was wäre die richtige Schreibweise?
- Me!Werte_UFO.Form.Requery oder
- Me!Werte_UFO.Requery

Gruß
Max

Hallo Max,

zunächst mal etwas grundsätzliches: in einem UFO wird nicht die ID eines DS gespeichert!

Was möchtest du eigentlich erreichen? Sollen die zwei UFOs über die ID synchronisiert werden oder geht es um eine reine Auswahl eines bestimmten DS?

Vielleicht beschreibst du mal mit anderen Worten, was genau du erreichen möchtest?

Gruß
Knobbi38

Zitat von: knobbi38 am November 29, 2024, 11:47:58Was möchtest du eigentlich erreichen? Sollen die zwei UFOs über die ID synchronisiert werden oder geht es um eine reine Auswahl eines bestimmten DS?

Letzteres!

In dem Auswahl-Ufo sind Projekte gelistet, die durch die Speicherung ihrer ID in der Werte-Tab (2. Ufo) auch für andere Formualre als Vorgabe bzw. Filter gelten sollen.

Gruß
Max

Hallo Max,
Für solche Aufgaben

Zitatauch für andere Formualre als Vorgabe bzw. Filter gelten sollen.

verwende ich öffentl. Properties in einem allgem. Modul. Die können von
überall beschrieben und gelesen werden.
Private m_CurrentProjektID

Public Property Let CurrentProjektID(NewID as Long)
    m_CurrentProjektID = NewID
End Property

Public Property Get CurrentProjektID() As Long
    CurrentProjektID = m_CurrentProjektID
End Property[/quote]
schreiben
CurrentProjektID = Me.ProjektID
lesen
Irgendwas = CurrentProkektID
'in Abfragen z.B.
"...WHERE ProjektID = " & CurrentProkektID
gruss ekkehard

@Ulrich

Zitatzunächst mal etwas grundsätzliches: in einem UFO wird nicht die ID eines DS gespeichert!

Wie meinst du das?
In meinen UFos gibt es die ID der UFo-Tabelle und den FK zum HFo.

Hallo Ekkehard,

wenn bei Deiner Variante die ID nicht in einer Tab gespeichert wird,
ist diese doch nach Beendigug von AC futsch, oder?

???
Wo kommt die ID denn her? Die muss doch in der Datensatzherkunft
des UFo (Tabelle) vorhanden sein.
Die Properties dienen doch nur dazu die ID zwischen zu speichern,
so dass du während der Laufzeit darauf zugreifen kannst, und dich
nicht darum kümmern musst in welchem Form die angezeigt wird, -
Vermeidung von Formularbezügen.

Zitat von: Beaker s.a. am November 29, 2024, 14:40:37Wie meinst du das?

Die ID ist ja in der Datenherkunft der Auswahl schon vorhanden und braucht deshalb in einem anderen UFO nocht mehr gespeichert werden, so wie es MAX ursprünglich beschrieben hat. Im Nachhinein will er gar nicht speichern, sondern nur dieses Wert nur zur Suche verwenden.  Der Titel des Themas ist deshalb etwas missverständlich.

Zitat von: MaxP am November 29, 2024, 13:34:00die durch die Speicherung ihrer ID in der Werte-Tab (2. Ufo) auch für andere Formualre als Vorgabe bzw. Filter gelten sollen.

Dafür muß die ausgewählte ID nicht in einer Tabelle gespeichert werden.

Für so etwas würde ich auch kein UFO wählen, sondern ein nicht modales POPUP-Formular. Dieses Formular kann geöffnet bleiben und bei Bedarf versteckt oder sichtbar gemacht werden. Dann wird dieses POPUP-Formular mit einer Public Property versehen, über die man die gerade selektierte ID abrufen kann, ohne die Interna des Formulars selber kennen zu müssen.

Alternativ zur Public Property, wie in #3 beschrieben, könnte man auch einfach eine Tempvar verwenden. Das erspart ein extra Modul und den Zugriff auf ein Formular per Formularreferenz; zudem kann diese Variante überall eingesetzt werden, also auch direkt in Abfragen usw.

Gruß
Knobbi38

Zitateine Tempvar verwenden.

Damit kann ich mich irgendwie nicht anfreunden.

@Ekkehard

Tempvars sind ausgesprochen praktisch, weil sie auch nach einem Programmfehler/-abbruch ihren Wert behalten.

Wenn man sie in Abfragen verwendet, reicht es, den Inhalt zu ändern und anschließend einfach ein Requery für das Steuerelement, z.B. Comboxbox, Listbox usw. aufzurufen. Auch für Reports sind sie bestens geeignet und Formularreferenzen braucht man auch nicht mehr.

Im MOF hatte ich mal einen Beitrag darüber verfasst, welche Vor- bzw. Nachteile die verschiedenen Adressierungsmöglichkeiten für den Zugriff auf die Tempvars haben und wie man sich da etwas vereinfachen kann. Leider gibt es das MOF so nicht mehr.

VG
Ulrich

Vielen Dank für die Tipps.

Leider kenne ich mich weder mit Public Property noch mit Tempvars aus.
(Wobei sich beides interessant anhört.)
Ich muss gestehen, dass ich das Beispiel von Ekkehard nicht ganz nachvollziehen konnte.

Da ich ein Freund der einfachen Programmierung bin, frage ich mal,
was von beiden einfacher ist?

Gruß
Max

Hallo Max,

das sind Grundlagen zu Access/VBA, welche man eigentlich kennen sollte. Im Zweifelsfall schaut man in die Dokumentation (https://learn.microsoft.com/de-de/office/vba/api/access.tempvar) oder liest das in einem Fachbuch nach. Sicherlich gibt es auch gute Artikel zu diesen Themen im Internet.
https://www.tksoft-online.de/ms-access/bsp-db-s/bsp-downloads-sonstiges/61-arbeiten-mit-tempvars.html (https://www.tksoft-online.de/ms-access/bsp-db-s/bsp-downloads-sonstiges/61-arbeiten-mit-tempvars.html)

Beides ist relativ einfach umsetzbar.

Gruß
Ulrich

Hallo Ulrich,

Wenn man nicht weiß, dass es etwas Neues gibt, ist man auch nicht in der Lage, es zu recherieren.

Egal, die Tempvars kommen für mich leider nicht in Frage, da diese wohl erst ab A07 zur Anwendung kommen können.

Gruß
Max

Hallo Max,


ja sorry, daß mit deiner Version hatte ich glatt übersehen. Vielleicht solltest du mal über ein Upgrade nachdenken, denn da fehlen auch noch andere Dinge, wie das neue DB Format, Layouts usw. ?  ;)

Dann solltest du das mit dem Beispiel von Ekkehard aus #3 umsetzen.

Übrigens schau mal nach, wenn du in der VBE in einem Modul den Menüpunkt "Einfügen -> Prozedur" aufrufst  (gibt es schon ewig). Wenn du 2003 hast, dann gibt es sogar noch die lokale Hilfe. Suche dort mal nach Property oder markiere das Wort Property und dann mit {F1} weiter. 

Gruß
Ulrich

Siehe auch:
https://www.akademie.de/de/wissen/vba-prozeduren-parameter-optimieren/properties-statt-funktionen (https://www.akademie.de/de/wissen/vba-prozeduren-parameter-optimieren/properties-statt-funktionen)
https://learn.microsoft.com/de-de/office/vba/language/concepts/getting-started/writing-a-property-procedure (https://learn.microsoft.com/de-de/office/vba/language/concepts/getting-started/writing-a-property-procedure)

Hallo Ulrich,

ich habe gerade gegooglt und was über globale Varaiblen gelesen. Ist wohl nicht das Gleiche wie Properties aber ähnlich. Ist das evtl. universeller und einfacher zu händeln?

Gruß
Max

Hallo Max,

natürlich kannst du auch globale Variablen verwenden, obwohl das "Bad Practice" ist und zu vermeiden ist.
Properties haben grundsätzlich den Vorteil, daß du die Kontrolle über Lese- und Schreibvorgänge behältst und spätere Änderungen einfacher machen.

Einfaches rudimentäres Beispiel:
Du möchtest die Änderungen einer globalen Property verfolgen, dann reicht es, eine Debug-Anwesung einzustreuen. Mit einer globalen Variablen ist das nicht möglich.

Warum sträubst du dich so vehement gegen Properties? In jedem Programm werden die doch ganz normal und häufig verwendet, z.B. wenn du bei einem Label die Caption Property neu zuweist oder bei einer Textbox per .Value Property den Wert ausliest. 

Hallo Ulrich,

Die eingebauten Properties sieht er aber nicht bzw. ist ihm
wahrscheinlich nicht bewusst, dass es sich überhaupt um solche
handelt.

@max
In einem deutschen Access nennt sich das "Eigenschaften" von
Objekten.
In diesem Fall stimmt das allerdings gar nicht. Eine benutzer-
definierte Property ist im Prinzip eine Funktion (Methode), die
keinem Objekt zugewiesen ist, sondern nur die Membervariable setzt
(Let/Set) oder ausliest (Get).

gruss ekkehard

Sorry, ich bin nun mal kein gelernter Access-Profi mit ausgefeiltem Background, sondern nur ein Autodidakt, der nach dem Prinzip Trial and Error handelt/handeln muss. Und jede nicht geschriebene Programmzeile ist eine gute Zeile, solange das Programm läuft. Wenn es denn läuft.

Ich habe ein Modul mit folgendem Inhalt:
Public MeinFilter As LongIch habe eine Fuktionen zum Setzen der Variable:
MeinFilter = Me!Eingabe
Und so sollte der Wert in einer Abfrage genutzt werden:
SELECT * FROM MeineTabelle WHERE MeinFeld = [MeinFilter];Nur das funktioniert nicht!

Gruß
Max

Hallo Max,

Zitat von: MaxP am Dezember 02, 2024, 17:52:48Und jede nicht geschriebene Programmzeile ist eine gute Zeile, solange das Programm läuft.

Das ist im Prinzip richtig, aber nicht immer ist Einfach auch gleich besser. So kann man z.B. alle Fehlerabfragen weglassen und solange nichts unvorhergesehenes passiert, läuft das Programm. Das große Erwachen kommt  möglicherweise etwas später und wird im Fehlerfall dann mit einer aufwendiger Fehlersuche belohnt.

Zitat von: MaxP am Dezember 02, 2024, 17:52:48... sondern nur ein Autodidakt

Ich denke, du möchtest dein Wissen schon noch erweitern und etwas dazu lernen, oder?

Ob die SQL-Anweisung so läuft, hängt davon ab, wie sie aufgerufen wird. Innerhalb von VBA mußt du die Variable evaluieren, sprich den Inhalt als String zu einem gesamt SQL-String zusammenfassen, weil SQL VBA nicht kennt (siehe #3).

Für Abfragen übernimmt das der Expression Service von Access, der aber in diesem Fall nur VBA Funktionen evaluieren kann. Deshalb muß eine globale Variable oder Property immer in eine Funktion gepackt werden:
Public Kriteria As Long

Public Function GetKriteria() As Variant
 GetKriteria = Kriteria
End Function
Für einen Property in einem Modul würde das ähnlich aussehen.

Der Aufruf wäre dann:
SELECT * FROM Table WHERE ID = GetKriteria()
Eine Tempvar hingegen kann direkt aufgelöst werden und braucht keine Funktion:
SELECT * FROM Table WHERE ID = Tempvars!KriteriaLeider wird das von ACC2K3 noch nicht unterstützt.

Gruß
Ulrich

Zitatder aber in diesem Fall nur VBA Funktionen evaluieren kann

Oder eben öffentliche Properties, die ja nichts anderes machen, ausser
die Möglichkeit zu bieten auch einen Wert zu schreiben.

@Beaker s.a.

Zitat von: Beaker s.a. am Dezember 03, 2024, 17:50:06

Zitatder aber in diesem Fall nur VBA Funktionen evaluieren kann

Oder eben öffentliche Properties, die ja nichts anderes machen, ausser
die Möglichkeit zu bieten auch einen Wert zu schreiben.

Genau das geht eben in einer Abfrage nicht. Weder wird eine globale Variable noch eine globale Property in einer Query unterstützt.

Grüße
Ulrich

Hallo zusammen,

die Zusätze zur Funktion fehlten bei mir. Nun funktioniert es aber.
Nun muss ich Variablen einbinden.

Sofern ich damit Probleme bekomme, komme ich vielleicht noch mal auf die Properties zurück.

Danke an Euch beiden!

Gruß
Max