Office: Berichte aus FE-Anwendung in eine mda auslagern

Hallo zusammen,

eine immer wieder gestellte Frage, ist die nach der Auslagerung von Berichten aus dem eigentlichen Anwendungsfrontend.

Mögliche Scenarien für dieses Erfordernis:
- Es gibt es Anwendungen, die an mehrere Kunden weitergegeben werden, welche individuell gestaltete Berichte haben wollen.
- Der Anwender soll die Berichte selbst gestalten können aber keinen Einblick in das Frontend bekommen.
- Anwendungen, die als mde weitergegeben werden, müssen bei Berichtsänderungen komplett neu kompiliert werden.
- ...

Am Ende des letzten Live-Meetings stellte Josef kurz die Möglichkeit vor, das Ganze über eine mda-Bibliothek zu realisieren.
Inzwischen hat er auch ein (klassenintesives *wink.gif*) Beispiel zur verfügung gestellt.

Zu finden ist dieses hier: BerichtAusMDAoeffnen.zip

Während ich mich durch den (klassentypischen) Code gekämpft habe, sind einige Fragen aufgetaucht, die zumeist einzelne Codezeilen betreffen:

Anwendung/Klassenmodul AT_ReportAssistant
Code:

Warum steht hier CodeProject und nicht CurrentProject? Die Hilfe bietet nicht viel zu CodeProject! Ist das grundsätzlich immer der Pfad zu EINER Bibliotheks-mda? Was passiert wenn man mehrere mda's verwendet (evtl. in verschiedenen Verzeichnissen)?

Berichte / Modul Constants
Code:

Wofür steht bzw. was ist der Anwendungsfall um 'Option Private Module' zu verwenden. Die Erläuterung in der Hilfe hat mir nicht wirklich neue Erkenntnisse gebracht.
Auch die Bedeutung/Verwendung von %SOURCE% stellt mich vor ein Rätsel.

Berichte / Modul Static und Modul ProzedurenFuerZugriff
Warum die zwei Module, hätte nicht eins gereicht? Oder ist das der "Kapselung in der 7. Normalform" geschuldet? *wink.gif*

Berichte/Klassenmodul AT_AddInReportAssistant
Code:

Das Objekt Dictionary kenne ich nicht. F1 bringt leider nur ein weißes Fenster. Kurze Erläuterung erwünscht.
Bedeutet auch, dass der Verweis zur Microsoft Scripting Runtime gesetzt sein muss. Ich gehe davon aus, dass diese auf JEDEM Windowssystem vorhanden ist?!?
Code:

Bitte um Erläuterung des letzten Parameters (DataSource). Dieser sollte, da er nicht in der Anwendung aufgerufen wird, immer vbNullString beinhalten. Daher ist mir die Prüfung auf StrPtr(DataSource) nicht einleuchtend.
Ich kann an der Stelle nur ins Blaue vermuten, dass ein SQL-String als Datenherkunft übergeben werden kann?

Berichte/Report_Bericht1
Code:

Bitte um kurze Erläuterung
ist die Tabelle1 hier fix und müsste für den Bericht angepasst werden?
Die Verwendung von DataSourcePlaceholder ist für mich nicht klar (siehe oben).

Für den Moment war das alles *biggrin.gif*
Vielleicht ist Josef ja auch so nett und zeigt allen Nicht-Klassenfreunden die "einfache" Modulvariante *wink.gif*


PS: Die beiden Felder für CurrentProject und Codeproject im Bericht bleiben bei mir beide leer.

:)

 

Hallo!

Das ist wie CodeDb und CurrentDb.

Damit sind die public Prozeduren von einem Standardmodul nur in der jeweilgen Anwendung erreichbar. Das ist Vorteilhaft, falls man das Add-In als Verweise einbindet, um Early binding während der Entwicklung verwenden zu können (vermeidet Namenskonflikte).

Die Idee dahinter: eine Möglichkeit bieten, um vom Frontend aus eine bestimmte Datenquelle (Jet-Backend oder ODBC-Connectionstring) zu übergeben.

Tabelle1 soll die Tabelle bzw. Abfrage symbolisieren, die die Datenbasis für den Bericht ist.
Das ist natürlich für jeden Bericht entsprechend einzustellen.

Als Ergänzung solltest du diesen Code betrachten:
Code:

Die Konstante DataSourcePlaceholder führte ich ein, damit ich mich im Code nicht vertippen kann. Nur einen String verwenden, könnte zur Folge haben, dass ich bei Änderung des Strings das Ändern an einer anderen Stelle vergesse.

Über GetDataSource hole ich mir die jeweilige Datenherkunft ab. Sollte z. B. als Datenherkunft ein Leerstring gespeichert sein, wird direkt auf die Tabelle in der mda zugegriffen. Ist eine Datenherkunft gespeichert, wird dieser String eingesetzt. Wurde keine Datenherkunft eingestellt, wird die Frontend-Datei verwendet.

Gibt es eventuel das Report.Load-Ereignis in deiner Access-VErsion nicht? => Report.Format ausprobieren.
Code:

Im Prinzip hätte auch ein Modul gereicht. Ich wollte mit den 2 Modulen aber die unterschiedliche Verwendung zeigen.
Anm.: Der Modulname "static" soll auf die Verwendung der Klassenverwendung hindeuten: nur ein einzige Instanz in der Anwendung zu erzeugen.

Gerade getestet: man kann aber auf die Funktion komplett verzichten, da man mit Application.Run auch eine Property-Prozedur aufrufen kann.
=> Es ist nur ein Modul erforderlich. ProzedurenFuerZugriff inkl. enthaltener Prozedur kann gelöscht werden.
=> Änderung in AT_ReportAssistant (in Anwendung.mdb):
Code:

mfg
Josef

 

Mit dem gesetzten Verweis auf Microsoft Scripting Runtime (die übrigens auch das FilesystemObject beinhaltet) solltest Du etwas finden können, zumindest im Objektkatalog. Die Bibliothek kann man auch per Late Binding einsetzen, also dann ohne Verweis, und sie wird ziemlich sicher auf einem aktuelleren Windowsrechner zu finden sein.

Ein Dictionary ist in seinen Eigenschaften und Methoden einer VBA.Collection ziemlich ähnlich und ein indiziertes Objekt. Man kann aber sowohl die Key-Auflistung als auch die Items-Auflistung direkt als Array verwenden und weitergeben. Somit werden Dictionaries gerne von fachkundigen Excelianern verwendet, um etwas Speed in ihren Code zu bringen. Daher findet man im Excelforum auch öfter Anwendungsbeispiele für Dictionaries, während man in einer Datenbank eher indizierte Tabellen verwendet.

 

Hallo!

Modul-Version.zip
Dieser Code sieht einfacher aus, er kann aber auch weniger. *wink.gif*

mfg
Josef

 

\@Josef

Soweit war mir das klar. Ist denn CodeDB immer eindeutig? Was, wenn die Anwendung mehrere mda's hat. Z.B. Berichte_1.mda und Berichte_2.mda? Oder geht das nicht?

Das ist doch schon übersichtlicher und erfüllt die Zielsetzung des Minimalprinzips *Smilie
Obwohl ich nun auch die Klassenlösung komplett verstanden habe ... glaube ich *wink.gif* Werde mal versuchen beide Varianten produktiv umzusetzen. Ade WE *frown.gif*

@Eberhard
Danke für die Erläuterung. Ich sah mir schon die Methoden und Eigenschaften im Objektkatalog an und hatte ähnliches vermutet. Wollte aber gerne eine Bestätigung haben. *cool.gif*

 

Zu CodeDb vs. CurrentDb bzw. CodeProject vs. CurrentProject:
CodeDb und CodeProjekt gelten immer für jende Anwendung in der der gerade ausgeführte Code steht.
CurrentDb und CurrentProject verwenden die mdb der Access-Instanz.
Soblad du in einem Add-In CurrentDb verwendest greifst du auf die DB der Anwendung zu, die das Add-In startete.

In der Anwendung kannst du CodeDb oder CurrentDb verwenden. Du wirst damit niemals auf eines der geladenen Add-Ins zugreifen.

Code:

Beachte bei diesem Code, dass CodeProject nur zum Auslesen der Verzeichnisses dient, in dem die Anwendung.mdb gespeichert ist. Damit wird nicht das Verzeichnis der mda-Datei ermittelt.

mfg
Josef

 

Daher hätte ich hier eher CurrentDb verwendet um den Bezug zur Anwendung zu verdeutlichen. Nun ist mir aber klar, dass das auf Anwendungsseite identisch ist und nur beim Code in der mda unterschiedliche Ergebnisse liefert. Danke dir!

 

Hallo!

Die Frage ob CurrentDb oder CodeDb würde ich gerne einmal andersherum stellen: Warum wird eigentlich immer CurrentDb verwendet? CurrentDb benötigt man eigentlich nur, wenn man aus einem Add-In oder eine Bibliotheks-mdb/mde auf die Datenbank der Anwendung zugreifen will.
Anm.: Bei mir ist es aus "Macht der Gewohnheit", dass ich oft CurrentDb statt CodeDb schreibe. Doch woher kommt diese Gewohnheit? *wink.gif*

mfg
Josef

 

Wer ausser dir kann das wissen? *wink.gif*
Ich gehe mal davon aus, dass CodeDB das selbe Instanzenproblem (bei Verwendung wird eine neue Instanz gestartet) wie CurrentDB hat, oder?

Einen entsprechenden Hinweis in der Hilfe zu CodeDB konnte ich jedoch nicht finden.
Somit könnte man sich den Einsatz von CurrentDBC durch CodeDB in der Hauptanwendung sparen?

 

Na, vom ABSCHREIBEN.
Wenn man nur immer das Gleiche abschreiben kann, festigen sich Gewohnheiten. Abschreiben heißt auch Übernehmen von offensichtlich Funktionierenden. Der Hang, da etwas kritisch zu betrachten oder gar besser machen zu wollen ist da eher gering ausgeprägt.

Kleines Extremum: "Wo muss ich das hinkopieren?"

 

Hallo Josef,

Du hast Recht. Eigentlich sollte CodeDb der Standard und CurrentDb die Ausnahme sein, die man ganz bewusst einsetzt.

Ich schließe mich da Erberhard an, abschreiben ist sicher einer der wesentlichen Gründe für diese Gewohnheit. Außerdem ist sicher auch die Tatsache, dass es in mehr als 99 % aller Fälle funktioniert (auch wenn es nicht notwendig gewesen wäre) dafür verantwortlich. Es gibt einfach keinen Grund den Code zu hinterfragen.
Ich gehe sogar soweit, dass ich behaupte, dass eine Vielzahl derer, die CurrentDb verwendet, gar nich weiß, dass es auch noch CodeDb gibt.

CU

 

Tach zusammen!
Insgesamt eine echt schicke Sache, das mit der Auslagerung der Berichte. Hätte mir das doch mal jemand vor 2 Jahren sagen können.

Eine Frage noch dazu:
Ich starte ich die Hauptanwendung um zu testen ob alles richtig läuft, stelle fest, dass in einem Bericht noch etwas geändert werden muss.
In dem Fall muss ich erst auch die Hauptanwendung beenden, da die mda-Bibliothek sonst für Änderungen gesperrt ist.
Kann man diese Verbindung aus der Hauptanwendung heraus irgendwie trennen, so dass diese nicht immer geschlossen werden muss, um an der mda-Bibliothek etwas zu ändern?

Solange man nicht mit Add-In oder Bibliotheks-DBs arbeitet, was m.E. auf den Großteil zutreffen dürfte, ist das ja auch nicht notwendig. *wink.gif*

Daher sehe ich auch

ein wenig anders. Für mich wäre der Einsatz von CodeDB schon semantisch ein Hinweis darauf, dass ich mich außerhalb der Benutzer-DB bewege.

 

Hallo!

Mir fällt keine Möglichkeit ein, ein Access-Add-In zu entladen.

Die Frage ist allerdings: Warum prüfst du den Bericht nicht gleich in der mda-Datei?

mfg
Josef

 

Die Berichte in der mda selbst aufzurufen funktioniert aus verschiedenen Gründen nicht.
Z.B.
- fehlen mir dann (zu übergebende) Filterkriterien
- es kommt zu Fehlermeldungen, da ich im Bericht eine Menüleiste eingestellt habe, die in der Hauptanwendung liegt. Der Bericht wird nicht geöffnet.

 

Hallo!

Diese Argumente sind mir zu wenig. *wink.gif*
Die Filterkriterien kannst du jederzeit mit einem Aufruf aus der mda simulieren.
Die Menüleiste könntest du eventuell in die mda übertragen oder den Bericht so anpassen, dass beim Start in der mda das Menü nicht angezeigt wird.

mfg
Josef