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, ...)
Zitat von: crystal am Juli 20, 2016, 14:45:15Oft 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.
Interessant dürfte noch sein, dass die TempVars auch in Abfragen verwendet werden können.
Und was das betrifft:
Zitatdie es seit Access 2013 (2010?) gibt.
seit A2007 genauer gesagt.
@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")...
?)
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
Hi,
ZitatWerden mit TempVars die Probleme normaler globaler Variablen umgangen?
Ja, der Inhalt von TempVars übersteht auch nicht behandelte Laufzeitfehler.
Für Makro-Programmierer von Web-Apps sind TempVars sicherlich interessant - für mit VBA programmierte Desktop-Datenbanken aber wohl eher weniger.
Zitat von: crystal am Juli 20, 2016, 16:05:33
@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.Zitat von: crystal am Juli 20, 2016, 16:05:33(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.
Hallo,
ZitatIch 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ß. ;D
Im Ernst, wozu braucht man in einer Datenbank 200 Formulare?
ZitatFormA für Kunde888 öffnet und FormB für Kunde999.
geht das nicht mit einem Formular das man entsprechen filtert ?
ZitatIm Ernst, wozu braucht man in einer Datenbank 200 Formulare?
In'ner DB keins, in'ner Anwendung dürfen's schon ein paar sein ! ;)
Hallo,
ich meine natürlich Anwendung. Und zwischen ein paar und 200 ist ein ziemlicher Unterschied.
@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".
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.
Zitat von: crystal am Juli 20, 2016, 20:26:12Es 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.
Zitat von: crystal am Juli 20, 2016, 20:26:12Ü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.
Zitat von: crystal am Juli 20, 2016, 20:26:12Und 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.
Zitat von: MzKlMu am Juli 20, 2016, 17:22:12Im 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.
Hallo,
ZitatUm 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 ? :D
Eine Anwendung nur danach zu beurteilen, wieviel Tabellen und Formulare und ... sie hat, ist etwas merkwürdig. Man müsste im gleichen Atemzug vergleichen, was die Anwendung macht und welche Funktionalitäten sie umsetzt.
Für mich ist es vorstellbar: Für die Belieferung eines VW-Werkes braucht man etwas mehr Equipment als zum Befüllen des eigenen Kühlschrankes.
Zitat von: MzKlMu am Juli 21, 2016, 23:44:32Wozu braucht man in einer Datenbank 250 Tabellen ? :D
Die Frage ist seltsam.
Das Backend einer SAP-Installation hat, je nach verwendeten Modulen und Customizing zwischen 20.000 und 60.000 Tabellen. - Wofür diese konkret gebraucht werden kann ich dir nicht beantworten. So lange es keine konkreten, gegenteiligen Hinweise gibt, würde ich aber vermuten, dass die Tabellen, so wie auch in meinem Fall, benötigt werden, um eine umfangreiche und komplexe Datenstruktur sinnvoll normalisiert abzubilden.
Hallo,
schon gut Ihr habt ja recht. Habe mich auch später geärgert, dass ich so vorschnell geantwortet habe. Aber den Beitrag löschen oder ändern wollte ich auch nicht, man weis ja nicht wie viele es schon gelesen haben.
Ich habe mich da von meinen Forumserfahrungen leiten lassen. Meistens schrumpfen hier vermeintlich notwendige viele Tabellen nach der Normalisierung auf wenige Tabelle mit wenigen Feldern zusammen.
Ich würde daher meine Einwände zurückziehen, waren so pauschal wenig sinnvoll.
Manchmal schreibe ich einfach zu schnell. ;D
Zitat von: PhilS am Juli 22, 2016, 09:52:17
Zitat von: MzKlMu am Juli 21, 2016, 23:44:32Wozu braucht man in einer Datenbank 250 Tabellen ? :D
Das Backend einer SAP-Installation hat
Bei einer Client-Server-Architektur gibt es kein "Backend". Außerdem ist im SAP die Datenbank nicht konsequent normalisiert.
Diese tempvars machen im Prinzip es nur leichter, globale Variablen zu definieren. Das macht es Laien einfacher, "intuitiv" loszuprogrammieren. Fördert aber einen unübersichtlichen Programmierstil. Außerdem sind die Variablen nicht typsicher.
Moin,
ZitatDas macht es Laien einfacher, "intuitiv" loszuprogrammieren. Fördert aber einen unübersichtlichen Programmierstil.
Und da sind TempVars nicht die einzige neue "Verbesserung", die MS uns
da an die Backe nagelt. Andere Beispiele:
Nachschlagefelder
Anlagefelder
Mehrwertfelder
:(
gruss ekkehard
Hallo,
wobei es Nachschlagefelder schon ewig gibt, mindestens seit A2000.
Was aber trotzdem die Verwendung nicht nach sich ziehen sollte.