Office: (Office 2016) Verschiedene Variablen für verschiedene Front Ends

Hi,

ich habe für verschiedene Standorte ein eigenes Frontend. Einzig und allein die in VBA genutzen Pfade für das öffnen/speichern von importen/exporten sollen sich unterscheiden.

Diese habe ich im Modul Pfade des Startmoduls so hinterlegt:

Code:

Der Grund für dieses zentrale Steuern ist, dass die Datenbank über unendlich viele Makros verfügt die auf viele verschiedene Pfadangaben zurückgreift.
Beim Verteilen einer neuen Version wäre es extrem aufwendig, die Pfade in jedem einzelnen Makro abzuändern.


Beim Start wird also die Public Variable mit den korrekten Pfaden des FrontEnds festgelegt. Das klappt in der Theorie ganz gut. Problem: Manchmal verliert Access die Public Variable "Exportpfad" die er beim Start der Anwendung gekriegt hat. (z.B. nach fehlerhafter Makro-Ausführung".

Jetzt könnte man bei jedem Sub, der die Pfade braucht vorneweg ein
Code:

hinbasteln. Aber irgendwie habe ich das Gefühl, dass das Ganze hier eine sehr unsaubere Lösung ist, für die ihr sicher tolle Vorschläge habt?

:)

 

Hallo,
verwende eine Tabelle zum Speichern der Variablen und hole diese mit Dlookup in Abhängigkeit der Abteilung aus der Tabelle.

Nachtrag:
In einer korrekt normalisiert aufgebauten Tabelle sollte es für die Abteilung eine Tabelle geben (mit nummerischem PK). In dieser Tabelle speichert man auch den Pfad.
Der Pfad wird dann so ermittelt:

Code:

Die richtige AbteilungID muss beim Start der DB ermittelt werden und statt der 1 im DLookUp verkettet werden.

 

Hallo,

sowas kann man doch problemlos in einer Tabelle hinterlegen und zur Laufzeit auslesen. Makros sind da nicht gerade übermäßig hilfreich, besser ist man mit sinnvoll aufgebautem VBA-Code dran. Bei dem gezeigten Makro brauchst Du für jede Filiale eine eigene Version, und das ist doch unpflegbarer Murks. Eine Funktion, die aus einer Tabelle den filialspezifischen Pfad rausholt, ist universell einsaetzbar, wenn sie den jeweiligen Filialkenner als Parameter bekommt.
Ungetesteter Luftcode:
Code:

Gruß
Fred

 

Um die Vorreden noch etwas zu ergänzen: Es würde sich die Verwendung eines zusätzlichen lokalen Client-Backends empfehlen. In diesem könnte der User - selbstverständlich über eine von Dir programmierte Einbindung und Oberfläche - seine individuellen Einstellungen speichern und auch wieder lesen. Das darf dann auch etwas mehr sein als nur ein paar Pfade.
Die Daten, die beim User liegen (bleiben), brauchst Du über Deine Aktualisierung der Frontends nicht verwalten.

 

Hallo,

ein lokales Client-Backend würde ich nicht empfehlen, weil u.U. dann Einstellungen nicht mehr zentral im "richtigen" Backend gewartet werden können.

Für solches Einstellungen verwendet ich eine separate Tabelle im BE mit Workstation/Usernamen als PK und einem Text-Feld, in dem alle Einstellungen gespeichert werden. In diesem Textfeld wird eine Klasse als serialisierter XML-String gespeichert, der dann einfach mit Dlookup geladen und deserialisert wird. Bei Beenden des Clients werden Aktualisierungen automatisch von der Klasse bei Bedarf wieder serialisert als XML-String zurückgeschrieben. Die Klasse selber stellt dann wiederum alle Einstellungen im Client zur Verfügung.

Im Prinzip funktioniert das so wie mit den Local/Rooming Appdaten im Windows-Profile.

Gruß Ulrich

 

Jetzt ernsthaft Ulrich.
Glaubst du wirklich, dass jemand der mit so einem trivialen Thema überfordert ist solche Aussagen versteht?

Außerdem dachte ich, dass man Objekte serialisiert und nicht Klassen.
Vielleicht solltest du eine etwas einfachere Sprache verwenden, die der durchschnittliche Copy & Paste "Programmierer"
der in der Regel noch nie eine Klasse programmiert hat versteht.

Edit:
Ich sehe grade: Beruf IT-Kaufmann. Was immer das auch ist. Durchdachte Programmier-Konzepte wohl eher Fehlanzeige.
Die kann man ja auch in Access anwenden.

 

\@markusxy:
Ja, natürlich serialisiert man Objekte und nicht Klassen. Entschudige, war vielleicht ein wenig abgelenkt. *upps
Aber sehe, daß du verstanden hast, was ich gemeint habe. *Smilie

Mir ging es darum, hier auch mal so ein Thema anzusprechen, weil es möglicherweise für den ein oder anderen interessant sein könnte. Eberhard (ebs17) hatte ja einen etwas anderen Ansatz vorgeschlagen.

Vielleicht kannst du das Thema ja nochmal aufgreifen und für die wirklich Interessierten mit deinen Worten ein wenig besser zusammenfassen?
Wäre vielleicht mal eine willkommene Abwechslung hier. *Smilie

Gruß Ulrich

 

Servus standby2
Dein Zitat:

Public Variablen verlieren ihren Wert, sobald ein nicht abgefangener
Fehler in der DB auftritt.
Versuch es einfach mal mit TempVar-Variablen, welche ab Access 2007
existieren und ihren Wert bei Ausführungsfehlern der DB nicht verlieren.
Hier findest Du Näheres dazu von Bitsqueezer
https://www.google.com/search?client...rs+bitsqueezer
Viele Wege führen nach Rom. Mein vorgeschlagener könnte für Deine Umstände ein vorerst durchaus praktikabler sein.

 

\@Urich:
Individuelle Einstellungen speichern Einstellungen zentral im "richtigen" Backend gewartet

Andere Verhältnisse und andere Anforderungen dürften auch unterschiedliche Wege und Maßnahmen nach sich ziehen.

Schon mal XML: Das lesen, auswerten und schreiben ist nun nicht jedermanns Tagesgeschäft. Das zum Lesen eines Pfades verwenden? Alle Achtung, wenn man die Erstellung inklusive Erlernen des Ganzen bezahlt bekommt.

Wenn ich mir die oben genannten Pfade ansehe: Man könnte da auch eine Mini-Benutzeranmeldung (Kombinationsfeld) verwenden und danach den Pfad mit der Filiale zusammensetzen. Da braucht man nicht unbedingt ausgefeilte Funktionen, Klassen usw.
Und wenn man das Formular mit dieser Auswahl offen lässt, genügt das, um fehlerunabhängig dort nachzuschlagen.

 

OT:
@Ulrich,
wie setzt du das eigentlich um?
Liest du die Klassen-Members direkt über das Klassen Interface oder verwendest du da einen anderen Ansatz?

Ich hab mir das mal für ein Projekt überlegt.
Da geht es in erster Linie um die Performance
Derzeit werden die Daten via Recordset geladen und in die einzelnen Objekte geladen.

Die Überlegung ist alle Objekte "serialisiert" in eine Binär-Datei zu schreiben und von dort direkt in die Anwendung zu laden.
Ich erwarte mir da über 95% Zeit Ersparnis. XML ist dafür natürlich unbrauchbar. Das wird dann eher viel langsamer statt schneller.

 

\@markusxy:
In VBA gibt es da leider nicht viel Möglichkeiten. Universell wäre, in der Klasse ein Interface "Serializable" einzubinden und dann zu implementieren. Die Klasse weiß ja selber, welche Member zu serialisieren sind. Ob jetzt XML, JSON, BINARY oder einfach TEXT ist ja zunächst mal egal.

Ich lade die Daten per Param-Query aus dem BE und dann wird der XML-String geparsed. Da ich das nur für Settings verwende, habe ich damit keine performance Probleme.

Aktuell verwende ich das für Druckereinstellungen, z.B. Paperbin, Colormode usw. und welcher Gruppen-Netzwerk-Drucker von welchem Arbeitsplatz aus genutzt werden soll. So kann der Admin diese Daten zentral im BE vorgeben, ohne an den Frontends irgend etwas einstellen zu müssen, beispielsweise, wenn ein Drucker wegen Wartung umgeleitet werden muß usw. Das sind in diesem Fall aber nur Vorgaben und können vom Anwender jederzeit in der angepaßten Backstage überschrieben werden.

Hier mal ein etwas andere Ansatz, allerdings erstmal für Excel:
How to serialize objects in VBA | Tips, Tricks and Code Snippets

Gruß Ulrich

 

\@Ulrich,
den Ansatz mit dem Auslesen der Members aus dem Link habe ich kürzlich gesehen.
Die notwendige tlbinf32.dll stammt wohl ursprünglich aus VB6.

Du speicherst also alle Eigenschaften in einem String?

Wenn ja, wie machst du die Pflege?
Mein erster Gedanke:
Ein ungebundenes Formular, das direkt mit dem Objekt interagiert wäre meine erste Überlegung.
Oder alle Werte in ein ungebundenes ADO Recordset laden und direkt an ein Formular binden.

Das grundsätzlich interessante an deiner Lösung:
Es spielt keine Rolle, wie viele Eigenschaften man für eine spezielle Einstellung braucht.
So ein Ansatz macht einen recht flexibel.

LG Markus

 

\@markus:
richtig: tlbinf32.dll stammt aus der VB-Classic Welt - setze ich selber aber nicht ein, da oft keine externen DLLs installiert werden dürfen bzw. Kompatibilität mit 64 Bit gewährleistet werden sollte.

"Du speicherst also alle Eigenschaften in einem String?"
richtig: besser XML-String.
Anbei mal ein Screenshot mit Testdaten von so einer Tabelle im BE.

Für die Pflege habe ich noch kein Tool. Das macht der Admin oder ich noch ganz klassisch von Hand, sprich CP in einen XML-Editor.
Man könnte aber auch einen universellen Editor auf Formularbasis entwerfen, der mit solchen XML-Schnipsel direkt umgehen kann und z.B. die XML-Daten in ein "fabricated Recordset" überträgt, welches an ein Formular/Unterformular gebunden wird.

Gruß Ulrich