TIPP: global verfügbare Daten

[crystal]

Liebe Leute,

heute möchte ich einen Tipp zum Besten geben.

Oft wird gefragt, wie man z. B. Daten an andere Formulare übergeben kann. Mit Aufruf-Parametern ist das zwar möglich, viel eleganter geht das aber mit der
TempVars-Collection,
die es seit Access 2013 (2010?) gibt.

Es handelt sich dabei schlicht um Access-Variablen, die im Memory gespeichert werden, so lange Access läuft. Sie können Strings und Zahlen aufnehmen, jedoch keine Objekte.

Die Arbeit mit TempVars ist denkbar einfach. Man vergibt einfach einleuchtende Namen (ohne weitere Deklaration) und den Wert, z. B.

TempVars("WillIchSpeichen") = "Mein Wert"
oder
TempVars("UserName") = txtUserName.Value

und kann dann überall darauf zugreifen, z. B.

Me.Caption = "Angemeldeter Benutzer ist: " & TempVars("UserName").Value

Damit ergeben sich ungeahnte Möglichkeiten, oder?

Grüße,

crystal

PS: über TempVars habe ich bisher nur wenig gehört, die Dokumentation ist etwas schwach.

Man könnte sowas in einem globalen Modul natürlich auch einfach selber bauen und weitere Funktionalität implementieren (save, restore, search, ...)

[PhilS]

Oft wird gefragt, wie man z. B. Daten an andere Formulare übergeben kann. Mit Aufruf-Parametern ist das zwar möglich, viel eleganter geht das aber mit der TempVars-Collection, die es seit Access 2013 (2010?) gibt.

Danke für den Tipp. TempVars sind in der Tat noch nicht so bekannt.

Eleganter finde ich diese Lösung allerdings nicht. Grundsätzlich finde ich es besser Daten möglichst direkt zu übergeben, als sie in irgendeiner Form von globalen Speicher zu hinterlegen. Damit ist wesentlich klarer aus dem Code zu erkennen, was wann wohin übergeben wird.

Die Handhabung von TempVar ist, besonders für Anfänger, natürlich einfacher. Damit haben TempVars für eher kleine und simple Anwendungen durchaus ihre Berechtigung.

[MaggieMay]

Interessant dürfte noch sein, dass die TempVars auch in Abfragen verwendet werden können.

Und was das betrifft:

die es seit Access 2013 (2010?) gibt.

seit A2007 genauer gesagt.

[crystal]

@PhilS
Jede(r) möge selbst entscheiden, was gerade 'eleganter' ist. Das Feature ist m. E. aber nicht nur auf kleinere Anwendungen beschränkt - schlicht weil es nahezu unbekannt ist oder war.

@Maggie
Danke für die Korrektur und den Hinweis auf Abfragen. Gerade letzteres erweitert die Access-Möglichkeiten natürlich gewaltig! (Oder wäre das mit einer selbstgebauten globalen Klasse auch möglich, etwa

...WHERE ... Tabelle.Feld = MyGlobalClass("UserName")...

?)

[Beaker s.a.]

Hallo,
Werden mit TempVars die Probleme normaler globaler Variablen umgangen?

Ich verwende lieber Public Propertys. Da kann ich vor jedem Gebrauch
erst mal den Wert checken, um nicht z.B. auf "unzulässige Verwendung von
NULL" (o.s.ä.) zu laufen.
gruss ekkehard

[MaggieMay]

Hi,

Werden mit TempVars die Probleme normaler globaler Variablen umgangen?

Ja, der Inhalt von TempVars übersteht auch nicht behandelte Laufzeitfehler.

[Lachtaube]

Für Makro-Programmierer von Web-Apps sind TempVars sicherlich interessant - für mit VBA programmierte Desktop-Datenbanken aber wohl eher weniger.

[PhilS]

@PhilS
Jede(r) möge selbst entscheiden, was gerade 'eleganter' ist. Das Feature ist m. E. aber nicht nur auf kleinere Anwendungen beschränkt

Es kommt natürlich immer auf die Anwendungen an.

Ein Beispiel:
Ich arbeite hier gerade an einer Anwendung mit ca. 200 Formularen. (Das würde ich als "mittelgroß" bezeichnen.)
Fast jedes Formular benötigt mehrere Parameter. Gehen wir mal davon aus es sind im Durchschnitt 2 Parameter. Die Parameter für Dialoge werden als OpenArgs übergeben, für andere Formulare werden sie als Public-Form-Properties gesetzt.)
Es ist vorgesehen, dass man durchaus FormA für Kunde888 öffnet und FormB für Kunde999.
Wollte man das mit TempVars realisieren, müsste man jetzt 400 (200*2) verschiedene TempVars verwenden.
Das ist nicht mehr sinnvoll zu handhaben.

(Oder wäre das mit einer selbstgebauten globalen Klasse auch möglich, etwa
...WHERE ... Tabelle.Feld = MyGlobalClass("UserName")...
?)

Ja, wenn MyGlobalClass eine Function ist, die den entsprechenden Wert aus einer Instanz der Klasse, oder besser Collection, ermittelt.

[MzKlMu]

Hallo,

Ich arbeite hier gerade an einer Anwendung mit ca. 200 Formularen. (Das würde ich als "mittelgroß" bezeichnen.)

200 Formulare ?
Da denke ich eher an suboptimal als mittelgroß.   
Im Ernst, wozu braucht man in einer Datenbank 200 Formulare?

FormA für Kunde888 öffnet und FormB für Kunde999.

geht das nicht mit einem Formular das man entsprechen filtert ?

[daolix]

Im Ernst, wozu braucht man in einer Datenbank 200 Formulare?

In'ner DB keins, in'ner Anwendung dürfen's schon ein paar sein  !

[MzKlMu]

Hallo,
ich meine natürlich Anwendung. Und zwischen ein paar und 200 ist ein ziemlicher Unterschied.

[crystal]

@PhilS
An einer Anwendung mit über 200 Formularen zu arbeiten (und dies auch noch zuzugeben ;-)) halte ich schon für etwas befremdlich...

Ich sage ja auch nicht, dass man nun alles mit TempVars machen soll, weit gefehlt. Es bleibt aber z. B. die Tatsache, dass TempVars auch bei ungewollten Stopps der Applikation bestehen bleiben - OpenArgs ja wohl eher nicht. Übrigens muss man ja im Code auch 200*2 OpenArgs definieren und dann im geöffneten Formular wieder zuordnen. Und niemand sagt, dass ich 200*2 verschiedene TempVars benötige, es wären wohl eher nur 2 (zwei) mit den schönen Namen "Argument1" und "Argument2".

[PhilS]

Das sind interessante Reaktionen. 

Was genau findet ihr an 200 Formularen suboptimal oder befremdlich?

Es handelt sich nicht um Fälle von ,,ich kopiere ein Formular 10 mal, weil sich eine Kleinigkeit geändert hat.". Jedes Formular hat eine individuelle Funktionalität und die Kombination aus den Daten und ihrer Darstellung ist jeweils in der Anwendung einmalig.

Ich hätte vielleicht mein Beispiel ,,FormA für Kunde888 öffnet und FormB für Kunde999." weniger abstrakt formulieren sollen. FormA wäre z.B. ein Adresseingabe-Form und FormB z.B. ein Form zur Angebotserstellung. Damit sollte klar werden, dass man hier nicht ein Formular mit verschiedenen Filtern verwenden kann.

Es bleibt aber z. B. die Tatsache, dass TempVars auch bei ungewollten Stopps der Applikation bestehen bleiben - OpenArgs ja wohl eher nicht.

Das ist natürlich ein netter Nebeneffekt, aber aus meiner Sicht sollte man unbehandelte Laufzeitfehler sowieso in seinen Anwendungen eher vermeiden.

OpenArgs bleiben übrigens bei einen Stopp der Anwendung ebenfalls erhalten.

Übrigens muss man ja im Code auch 200*2 OpenArgs definieren und dann im geöffneten Formular wieder zuordnen.

Jein. Die Übergabe muss natürlich programmiert werden, aber da die OpenArgs eine Property des Forms sind, ist die Zuordnung, welche OpenArgs zu welchem Form gehören, automatisch immer klar definiert.

Und niemand sagt, dass ich 200*2 verschiedene TempVars benötige, es wären wohl eher nur 2 (zwei) mit den schönen Namen "Argument1" und "Argument2".

Das ist natürlich möglich. Die Variante hatte ich nicht bedacht.

Unschön daran ist allerdings, dass du allein an dem Ausdruck TempVars("Argument1") nicht erkennen kannst, ob es sich bei Argument1 jetzt gerade um eine KundenNr, eine RechnungsNr, AuftragsNr, ImmobilienNr oder um sonst irgendwas handelt.

Ja, OpenArgs haben im Prinzip ein ähnliches Problem, weshalb ich die Argumente als Name-Value-Pairs übergebe (KundenNr=0815;RechnungsNr=4711).

Ich will hier nicht grundsätzlich gegen TempVars argumentieren, aber je komplexer eine Anwendung wird, desto wichtiger finde ich es, Daten möglichst ,,nah an dem Objekt" zu speichern, das diese Daten benötigt. Das macht zusammenhänge klarer erkennbar und hilft Entwickler-Fehler zu vermeiden.

[PhilS]

Im Ernst, wozu braucht man in einer Datenbank 200 Formulare?

Wie soll ich diese Frage beantworten?
Um die Daten aus den ca. 250 Tabellen der Anwendung darzustellen.
Es handelt sich um eine komplexe, etwas umfangreichere Anwendung.

[MzKlMu]

Hallo,

Um die Daten aus den ca. 250 Tabellen der Anwendung darzustellen.

fordert schon die nächste Frage heraus:
Wozu braucht man in einer Datenbank 250 Tabellen ?