Office: (Office 2013) Dekompilieren, kompilieren und komprimieren ohne DB zu öffnen

Hallo,

ich habe folgendes Szenario, für welches ich eine Arbeitserleichterung suche:

Mehrere Jugendverbände (gleicher Träger aus unterschiedlichen Bundesländern) nutzen eine Datenbank auf einem SQL Server mit Access als Datenbankfrontend. Allerdings ist pro Bundesland eine eigene Datenbank mit identischer Struktur auf dem Server eingerichtet, damit die Daten sauber getrennt sind und bei der Nutzeranmeldung z.B. nur die Nutzer des jeweiligen Verbandes angezeigt werden.

Im Access-Frontend ist in einer Tabelle hinterlegt, welche Datenbank angesprochen werden soll. Es gibt also pro Jugendverband ein eigenes Datenbankfrontend.

Meine Erfahrung mit der Verteilung der Frontends ist, dass es sich lohnt vor der Verteilung die DB zu dekompilieren, komprimieren und dann zu kompilieren. Zumindest habe ich damit deutlich weniger Probleme bei den Anwendern.

Als nur zwei Bundesländer die Datenbank nutzten war die Verteilung der Frontendupdates noch überschaubar. Zwischenzeitlich sind aber immer mehr eingestiegen und ich suche jetzt nach Lösungen, wie ich die Update-Dateien schneller vorbereiten kann.

Was ich jetzt schon mal hinbekommen habe ist mit einer zusätzlichen Datenbank die Frontends in die Verzeichnisse zu kopieren und die Daten in der jeweiligen Tabelle zu ergänzen:

Bsp:
C:\Quellverzeichnis\Frontend.accdb --> DB "Entwicklungsumgebung" im SQL-Server

VVVV

C:\Verband Bayern\Frontend.accdb --> DB "Bayern" im SQL-Server
C:\Verband NRW\Frontend.accdb --> DB "NRW" im SQL-Server
...
..

Um jetzt die kopierten Datenbanken zu dekompilieren könnte ich natürlich jede Datenbank mit "/decompile" aufrufen. Dann habe ich aber X Datenbanken offen. Zudem habe ich irgendwo gelesen, dass das dekompilieren möglichst mit gedrückter Shift-Taste erfolgen soll (wahr oder Legende?).

Meine Frage ist daher, ob ich via vba aus der anderen Datenbank heraus alle neu erstellten Frontends in den unterschiedlichen Verzeichnissen dekompilieren, dann komprimieren & reparieren und anschließend wieder kompilieren kann, ohne dass die Datenbanken dadurch geöffnet werden?

Ideal wäre, wenn anschließend auch noch gleich *.accde-Versionen erstellt werden.

Grüße

Stefan

:)

 

Wenn das alles ist, könnte man auch ein Frontend in der Entwicklung benutzen und nach allen Aktionen bedarfsgerecht kopieren und die bewusste Tabelle hineinschieben bzw. aktualisieren. Der dazu nötige Zugriff per DAO / ADODB käme einem Nichtöffnen ziemlich nahe.

Allerdings auch:

Trennungen an ungeeigneter Stelle verursachen zusätzliche Probleme.

 

Dieses Konzept ist mE unnötig. Du könntest das gleiche mit einem sauberen Berechtigungskonzept und serverseitiger Trennung der Daten über Views erreichen.

Wenn beim Start der DB automatisch Code ausgeführt wird, ist es dafür zwingend notwendig, dass dieser Code kompiliert wird. - Das kann der Intention eines /decompile natürlich zuwiderlaufen. - Ist aber mM kein signifinkates Problem, wenn du die DB ohnehin direkt anschließend in genau dieser Konfiguration/Umgebung vollständig kompilieren willst.

Das zu erreichen bedingt zwingend, dass die Datenbanken in Access geöffnet werden. - Aber du kannst den Prozess ja über ein Script steuern und musst nicht alles manuell machen.

Ich habe einen Artikel über AccDE Erstellung mit VB-Script veröffentlicht. Das sollte der schwierigste Teil dabei sein. Das funktioniert analog auch wenn du eine Access-Anwendung mit VBA anstelle von VB-Script verwendest.

 

Der Tipp mit der ACCDE-Erstellung war wirklich sehr hilfreich. Vor allem, weil sich Access dadurch nicht öffnet.

Gleiches gilt nebenbei für die Startoption /repair bzw. /compact. Das hab ich jetzt noch gefunden. Beide führen angeblich zum gleichen Ergebnis und entsprechen der Funktion "Komprimieren und Reparieren).

Damit bleibt eigentlich nur noch /decompile zu lösen. Gibt es denn dafür nicht auch so einen Syscmd?

Wobei es wohl auch so klappt, indem ich die Grunddatei dekompiliere und es bei den kopierten Versionen dann nicht mehr mache. Am Code ändert sich ja eigentlich nichts.

 

Ääh? - Du brauchst eine Access Instanz, um das SysCmd zur AccDe-Erstellung ausführen zu lassen. Daher kann ich nicht nachvollziehen, wie du das meinst.

/decompile ist doch aber nur eine Befehlszeilenoption, die du einfach per Script (oder was auch immer) ausführen lassen kannst. Ich verstehe nicht, was dein Problem dabei ist.

 

Also ich habe eine Updatedatenbank erstellt. Wobei die eigentlich nur eine Routine ausführt, mit der dann die eigentlichen Frontends vorbereitet werden.

Die Routine macht folgends:

a) Lösche alte Frontends:

- lösche DB1 in Verzeichnis 1
- lösche DB2 in Verzeichnis 2
- lösche DB3 in Verzeichnis 3


b) Kopiere aus Quellverzeichnis

- DBneu in Verzeichnis 1
- DBneu in Verzeichnis 2
- DBneu in Verzeichnis 3


c) Trage in die Tabelle "Verbindungsdaten" der Datenbanken ein

- Verbindungsdaten1 in DBneu in Verzeichnis 1
- Verbindungsdaten2 in DBneu in Verzeichnis 2
- Verbindungsdaten3 in DBneu in Verzeichnis 3


d) Komprimiere und repariere mit "/repair"

- DBneu in Verzeichnis 1
- DBneu in Verzeichnis 2
- DBneu in Verzeichnis 3


e) Erstelle ACCDB (mit deinem Syscmd)

- ACCDE1 in Verzeichnis 1
- ACCDE2 in Verzeichnis 2
- ACCDE3 in Verzeichnis 3


Zwischen c) und d) hätte ich eben gerne die Option /decompile ohne das dann 3 Datenbanken aufgehen, die ich danach noch per Hand schließen muss.

 

Ich mach diesen alten Thread von mir nochmal auf. Für mehrere Jahre hatte ich mir jetzt dahingehend weitergeholfen, dass ich die "Vorlagen-Datenbank" dekompiliert und komprimiert habe und dann die Verteilung erfolgt ist. Das hat eigentlich immer ganz gut funktioniert.

Mit den letzten Windows-Updates gab es ja dauernd Access-Probleme und aus irgendwelchen Gründen ist jetzt auch die Frontendverteilung betroffen. Obwohl die jeweiligen Verbindungsdaten sauber in die Frontends eingetragen werden und es per se keine verknüpften Tabellen o.ä. zum Server gibt (alles läuft über Stored Procedures im SQL Server) kommt beim ersten Start der Datenbank eine Fehlermeldung mit Verweis auf die Entwicklungsumgebung. Woher die kommt kann ich nicht nachvollziehen - die Verbindungszeichenfolge zur Entwicklung steht nirgends im Code oder anderswo.

Dekompiliert und repariert man die neuen kopierten Tabellen, dann funktioniert alles wieder wie gewünscht. Insofern wäre das ein wichtiger Schritt für mich vor der Verteilung. Allerdings startet der Befehl "/decompile" jedes Mal die Datenbank und genau das möchte ich nicht (oder automatisch wieder schließen). Weiß jemand, wie man die mit "/decompile" geöffnete Datenbank wieder automatisch einfängt und schließen kann?

 

Mit getObject eine Referenz auf die DB erstellen und dann schließen. *wink.gif*

 

Mir fehlt die Vorstellung, wofür das gut sein soll.
FE enthält nennenswert Tabellen, abgesehen von den Systemtabellen?
Tabellen enthalten Code, der zu dekompilieren wäre?
Neues muss gleich repariert werden?
Grauselig.

 

Hallo!

Probiere einmal die Schalter /decompile und /compact in einem Aufruf aus.

mfg
Josef

 

Mir fehlt auch oft die Vorstellung, weshalb Access so reagiert, wie es reagiert... *rolleyes.gif*

Tatsache ist, dass das Frontend eigentlich gar keine Tabellen enthält - außer ein paar lokale/integrierte Tabellen (Verbindungseinstellungen, Sperrstatus, Versionsnummer, Tickerverlauf).

Alle Daten werden über SPs vom SQL Server abgerufen. Insbesondere gibt es dadurch keine verknüpfte Tabellen.

Ein großes Problem bei unserer NGO / Jugenverband-Umgebung ist die sehr unterschiedliche PC / Officelandschaft. Ca. 30 User haben alle unterschiedliche Konstellationen (Notebook, fester PC, Windows in verschiedenen Varianten, Office 2013 - 2016 - 365 in den Versionen 32 und 64 bit). Insofern ist die Verteilung der Frontends eine Herausforderung, da man nicht einfach einheitlich z.B. eine ACCDE-Version verteilen kann.

Meine "Best Practice", die sich jetzt seit Jahren bewährt hat: eine komplett dekompilierte und komprimierte Version mit den jeweiligen Verbindungsdaten bestücken und verteilen. Die 64-bit-Freunde mit Access höher 2013 generieren sich mit der Updatedatenbank aus der ACCDB dann ein eigenes ACCDE.

Das war tatsächlich die gesuchte Lösung. Wenn man beide Befehle kombiniert, dann geht die Datenbank anschließend wieder zu.

Besten Dank! Damit hat sich ein lange ungelöstes Problem erledigt!