infobase: EDV - MS-Access

Runtime

Es empfiehlt sich übrigens auch innerhalb der Runtime-Version im Makro autoexec den Befehl Fenster ausblenden (von die Datenbankfenster) als ersten Makrobefehl auszuführen, um ein dreifaches Flackern verschiedener (Datenbank-Modul-) Menüleisten zu unterbinden.

****

Datenbearbeitende Formulare sollten in der Runtime-Version über eigene Standard-Menüleisten verfügen, da in der Standard-Runtime-Menüleiste zum einen in der Formularansicht im Menü Ansicht die Option Datenblatt fehlt und zum anderen in der Datenblattansicht die Option Formularentwurf angeboten wird, die zu abstrusen Vollbild-Umschaltungen und Ausblendungen führt, so daß für den Anwender erst wieder einmal gar nichts mehr geht !

Das geht sogar soweit, daß z.B. für profane Stammdaten-Aufgaben Tabellen geöffnet werden können, deren eigene Menüleisten in der Runtime-Umgebung eine Manipulation der Tabellen- und Feldeigenschaften zulassen ! Verhindert werden kann so etwas nur über ein anwendungsweites Menüleistenmakro, daß zu Beginn des Anwendungsstarts gesetzt wird (bzw. nach dem Antiflackern-Makroeintrag).

****

Die Auslieferung einer Accessanwendung mittels des (nach käuflichem Erwerb) lizenzfreien Runtime-Modules (z.B. MS-Access 2.0) führt zu dem Umstand, daß eine Anwendung innerhalb der normalen Accessumgebung oder eben in der Runtimeumgebung abläuft.

Das kann per Code unterschieden werden durch:

If SysCmd(SYSCMD_RUNTIME) Then

ERSTELLEN EINES SETUP-SATZES / PROBLEME in der RUNTIME-Umgebung:

die Arbeit mit dem Setup-Wizard (Wichsard):

- Bibliotheken a'la wzlib.mda von z.B. d:\@ aus einbinden, da der Setup-Wizard selbst welche braucht -> Zugriffsfehler
- Einbinden msacc20.hlp -> 5 Disks, sonst nur 3
- zusätzliche dll's a'la msau200.dll (OpenFile-Dialoge) aufnehmen
- erst einmal ein dummy setup zusammenstellen und speichern (noch keine Disketten-Repräsentationen erstellen)
- danach Editieren von zws_TemplateFiles, um die Anwendungsini im AppDir zu halten
- das Repräsentations-Stammverzeichis (d:\@\xyz) leeren (Wizard fuckt sonst ab)
- Diskettensatz erstellen
- Ergebnisse prüfen (Anzahl verwendeter Disketten-Verzeichnisse), nicht immer optimal im Bedarfsfall überschüssige Dateien umverteilen, disk4 eliminieren, setup.inf bearbeiten
- in disk1 die Datei setup.stf editieren (unterste Abschnitte): Die hier angeführten Schritte müssen nach einer evtl. Probe-Diskerstellung später noch einmal gemacht werden
- zum Teil gehen Kommandozeilen-Parameter verloren (in msarn-Hauptaufruf)
- ein evtl. /cmd xyz - Parameter muß hinten angefügt werden, sonst wird z.B. anstelle einer setup.ini im WinDir eine zufällig vorhandene msacc20.ini benutzt und es kommt zu Bibliotheksladefehlern (auch beim erweiterten Setup-Aufruf überprüfen)
- die Reihenfolge der Programm-Manager-Gruppen-Einträge bzw. das Hinzufügen eigener Einträge kann auch nur im Nachhinein erfolgen, zumal die Reihenfolge innerhalb des Setup-Wizards spinnert variiert
- Lesen von -> SETUP.STF
- Zusatz-Diskettenverzeichnis erstellen, wenn erweitertes Setup a'la dat013kl. Eine korrekte transact.mdb sowie eine dummy.mdb befinden sich hoffentlich in den erstellten Disketten-Repräsentationen
- die nächste (Probe-)Installation prüft hauptsächlich, ob die Änderungen der setup.stf ok sind. Wenn nicht, dann die von dem Setup im Installationsverzeichnis kopierte setup.stf nachbearbeiten, bis gut ist. Korrekte Version in d:\@\xyz sichern. (setup.stf evtl. sogar in getrennten Fassungen speichern s. dat013kl Master/Kunden)

- es kam auch schon mal vor, daß das Erstellen einer system.mda ohne Meldung unterblieb. Zwar konnte per manuellem wrkgadm.exe eine neue erstellt werden, doch trug sich diese Scheisse dann auch prompt in meine e:\windows\msacc20.ini ein. Fuck off !

* * * *

Was muß getan werden:

- Symbolleistenplazierung:
Satz erstellen, installieren, Symbolleiste ausrichten, dem Setupsatz hinzufügen, neu erstellen.

- die Datei setup.stf:
Dort werden u.a. die anzulegene Programm-Manager Gruppe und Icons festgelegt. In der finalen Setup-Version überarbeiten.

- evtl. Zusatzdateien
- Datei öffnen-API-Dialoge erfordern die msau200.dll.

- Hilfesystem: Traurig, zumal der Setupdiskettensatz von 3 auf 5 anschwillt !
- Hilfedatei msacc20.hlp im Anwendungsverzeichnis mitliefern
- Function API_WinHelp muß installiert sein
- sowie das Hilfemakro 'Hilfe' (siehe bestatt.mdb)

- OCX-Steuerelemente
- im Rahmen des Setup-Wichsers passabel, aber wehe, wenn sie später eingebunden s. OCX-Steuerelemente nachträglich einbinden.

Nach all den oben beschriebenen Problemen muß der Gedanke mit MS-ACCESS eine Software zu erstellen, die obendrein über programmierte Setup-Routinen verfügt, als beinahe undenkbar verworfen werden.

Nachdem in dem für teures Geld erworbenen Developers Toolkit aber ein Setup-Wichsard enthalten war und eine entsprechende Option z.Bsp. von BOSCH gewünscht wurde, ging auch dieser Kelch nicht an mir vorüber.

Im folgenden eine kleine Aufstellung der Nettigkeiten, die einen hier erwarten:

* * * *

Der Versuch, mit einer transact.mdb mehr als eine Aufgabe von einem Programm-Manager-Icon aus zu erledigen, muß trotz trickreichster Versuch als gescheitert angesehen werden. Es bestünde zwar noch die Möglichkeit, nach erfolglosem Tabellen-Fälschen die setup.stf dahingehend zu editieren, daß eine transact.mdb-Datei mit mehreren Aufgaben im Programm-Manager beauftragt wird (allerdings sollte sie mit einer dummy_tr.mdb künstlich dem Setup-Satz hinzugefügt werden.), oder man läßt die ganze Scheiße und erzeugt redundant mehrere Kopien mit verschiedenen Namen. Aber was ist, wenn diese transact-Kopien gepflegt werden müssen ? Weiß ich dann später noch, wer wieviele Kopien einer transact.mdb unter welchen Namen auf seinem System laufen hat ?

So eine Scheiße !

Zuweilen kommt man dann auch auf so Ideen, wie namensrelevante dummy-Dateien ins Setup aufzunehmen, die dann hochwichtig in die Programmgruppen eingetragen werden. Ein sog. erweitertes Setup (würg) kann dann die echten Dateien, die auf Extra-Disketten sogar leicht updatebar sind, anfassen und in das Zielverzeichnis kopieren.

Um bei Bedarf mehrere Icons für verschiedene Aufgaben einer einzigen transact.mdb anzulegen, sollte man sich auf das Editieren der setup.stf-Datei gefaßt machen.

* * * *

INI-Dateien ins Anwendungsverszeichnis:

Ein Lichtblick konnte beim Editieren der Tabelle zws_TemplateFiles im Feld dest am düsteren Softwarehimmel vernommen werden. Für im Setup integrierte Ini-Dateien ist im Setup-Wichsard das Feld für das Zielverzeichnis disabled und mit $(WINDIR) versehen, was zur Folge hat, daß nach bester Microsoft-Manier alle Ini-Dateien im Windows-Verzeichnis landen. Das kann so sein, muß aber nicht, wie viele Spiele-Programmierer und auch die Fa. Autodesk bewiesen haben. Nun, wenn man in diese Tabellenfelder den Eintrag $(APPDIR) übernimmt, was der Setup-Wichsard natürlich nicht erlaubt, haut das eben alles hin.

Unerschrockene könnten sogar versuchen, in setup.stf so Einträge wie 'InstallSysFile' z.B. durch ein beherztes 'copyfile' zu ersetzen. Vielleicht kann man dann das Setup dazu bringen, alle installierten Dateien in das Anwendungsverzeichnis zu kopieren. In Anbetracht billiger Riesenplatten ist das schon lange kein Thema mehr, die Aussicht auf eine 100%ig fehlerfreie Deinstallation dagegen sehr.

*

Reihenfolge der in der Programm-Manager-Gruppe angelegten Gruppe:

Am besten den Setup-Wizard-Eintrag als ersten nehmen, der auch als erstes Icon erscheinen soll. Entsprechend der gewünschten Icon-Reihenfolge die Reihenfolge der Setup-Wizard-Einträge wählen. Falls sich in der Setup-Wizard-Vorlage z.B. ein Info-Eintrag in der Liste vor die Hauptanwendung gemogelt haben sollte, den "Vordringling" löschen, das Setup speichern und danach den unwichtigeren Eintrag wieder in das Setup aufnehmen. Das sollte zumindest dafür sorgen, daß diese Einträge in der setup.stf in der richtigen Reihenfolge stehen.

Das haut aber bei mehr als drei Einträgen auch nicht unbedingt hin. Ein vorsichtiges Editieren der Datei setup.stf (Aufzählungs-Index in erster und zweiter Spalte) hat dann aber doch den gewünschten Erfolg gebracht.

*

SETUP.STF

Tja, der Weg ist das Ziel und Scheiße fließt nach unten.

Die umständliche Rummacherei mit transact.mdb, um Reparier-, Komprimier- und Backup-Geschichten auf die Reihe zu kriegen, kann auch über mutiges Editieren der setup.stf erledigt werden. Klar, daß der Setup-Wichser sowas nicht auf die Reihe kriegt.

Im Abschnitt 'User ProgMan Items' stehen die anzulegenden Icons mit Beschreibung, Befehlszeile etc.

Es können auch handverlesene Programm-Manager-Einträge durch das Editieren der setup.stf erzwungen werden. Ein Eintrag, der ein Icon für den msarn200-Aufruf zum Reparieren und Komprimieren der Anwendung erstellen sollen, kann wie folgt
aussehen:

<327        USER_UserPM_3        AddProgmanItem    """nb21 - Projektdatenbank"", ""reparieren und komprimieren"", ""%25\msarn200.exe %317\nb21.mdb /repair /compact /ini %319\nb21.ini"", ""%318\nb21.ico"""                            >

Beim Einfügen solcher Zeilen muß aber beachtet werden, daß

- die ID-Nummern fortlaufend sind.
- zusätzlich eingefügte Programm-Manager-Einträge 'USER_UserPM_1' fortlaufend sind.
- der Separator-Eintrag '---- User Non File Work ----' angepaßt wird; er nennt die Zeilen-ID's der Separator-Zeilen '---- User ProgMan Items ----', '---- User INI Entries ----' sowie die abschließenden Aktionseinträge 'Create SYSTEM.MDA' und 'Run Command at End'. Anmerkung: 'Create SYSTEM.MDA' ist nicht vorhanden, wenn system.mda im Setup.
- die neuen Zeilen auch in 'User ProgMan Items Group 325 326 327 328' stehen.
'Group 324 329' verweist auf die ID's der folgenden Kapiteleinträge. Vorsicht, die ID-Nummern sind mit Blanks abgesetzt, danach folgen aber Formatierungs-Tabs. Das ist auch schon mal schiefgegangen. Auch beim Folge-Separator beachten.
- auch andere derartige Nennungen bei eingefügten und verschobenen Zeilen angepaßt werden.
- der Eintrag 'Maximum Object ID 123' (oben) die richtige Maximal-Zeilenanzahl nennt.

Sogar das manuelle Umverteilung bei schlechter Optimierung der Setup-Daten ist möglich:
Ist z.B. eine kleinere Datei, die noch in eines der Disketten-Verzeichnisse gepasst hätte, in ein eigenes Disketten-Verzeichnis gerutscht, kann folgendes getan werden:
- diese Datei in ein geeignetes Disketten-Verzeichnis kopieren.
- das unnötige Disketten-Verzeichnis löschen
- die Datei setup.inf in notepad laden
- im Abschnitt [Source Media Descriptions] den überflüssigen Diskverweis entfernen
- den Dateieintrag z.B.

<"wrkgadm"= 4,WRKGADM.EXE>

<"wrkgadm"= 1,WRKGADM.EXE>

* * * *

Makro autoexec:

Sollte auch in Runtime-Umgebung als ersten Befehl Fenster ausblenden enthalten, um Mehrfacheinblenden diverser Menüleisten zu vermeiden.

Wenn in der Anwendung auch Tabellen grafisch geöffnet werden sollen, dann sollte ein Anwendungs-Menüleistenmakro hinterlegt werden, damit so Sachen wie Ansicht / Tabellenentwurf nicht angeboten werden.

* * * *

Jedem datenbearbeitenden Formular sollte eine eigene Standard-Menüleiste zugewiesen werden, um wirre Optionen (z.B. Formularentwurf in der Datenblattansicht-Menüleiste) mit wirren Folgen (völliger Bild-Zusammenbruch) erst gar nicht anzubieten.

* * * *

Selbst die INI-Dateien können einen zum Narren halten.
Z.B. werden im Falle Strobel Aufrufe einer Access-Runtime-Anwendung sowohl vom Windows-Programm-Manager wie auch vom DOS-Shell-Menü ausgeführt. Die Anweisung der auszuführenden Befehleszeile

c:\strobel\msarn200.exe e:\bestatt\bestatt.mdb /ini e:\bestatt\bestatt.ini

sowie das entsprechende Arbeitsverzeichnis 'e:\bestatt' sind in beiden Fällen identisch hinterlegt. Trotzdem gelingt der Aufruf aus dem DOS-Shell-Menü heraus nicht so richtig, da in der ini-Datei hinterlegte Bezüge auf z.B. Icons, Bibliotheksdatenbanken und SplashUp-Logos nicht gefunden werden, während das vom Programm-Manager aus gelingt. Auf Jangos Netzmaschine kam es sogar zu so richtig schönen Netz-Scheissfehlern. Erst das explizite Hinterlegen der entsprechenden Pfadangaben für diese Dateien in dieser ini-Datei beendete diesen Spuk.

* * * *

DRUCKEN von Formularen / STANDARDDRUCKER:

Völlig erstaunt mußte ich im Hause BOSCH feststellen, daß beim Formulardruck (Standarddrucker ist dort ein HP III ) Access sich über das Nichtvorhandensein meines Panasonic KXP 1123 beklagte. Erst ein Umstellen über die Access-eigene Druckereinrichtung mit dem Bosch-Access brachte den gewünschten Erfolg.

Es gibt angeblich eine Ini-Option, die den Access/Formular-intern gespeicherten Drucker ignoriert und stattdessen den Windows-Standard-Drucker benutzt.

Da das Problem aber sonst nicht mehr auftrat, liegt die Vermutung nahe, daß bei den Problem-Berichten bei mir in der Druckeinrichtung, die bekannterweise Einstellungen berichts-spezifisch speichert, testweise ein spezieller Drucker eingestellt wurde, der dann natürlich beim Kunde nicht vorhanden war. Diese 'Druckereinrichtung's-Optionen a'la Ränder etc. werden eben von Access zum Bericht gehörend gespeichert.

Eine wieder aufgetauchte Kurznotiz zum Thema Ini-Eintrag deutet auf folgendes hin:

msacc20.ini:

[Microsoft Access]
UseDefaultPrSetup=1

Leider konnte der Hinweis später in keiner Dokumentation mehr gefunden werden, aber als Workaround tut's auch, wenn man beim Entwerfen von Berichten an der Einstellung 'Standarddrucker' nichts dreht. Sollte da was geändert werden müssen, so wird das eben brav über die Systemsteuerung gemacht.

Auch das Zuweisen exotischer Papierformate in den Berichts-Druckeinrichtungs-Eigenschaften bereitet Verdruß. Gerät der Bericht an einen anderen Standarddrucker, als bei der Zuweisung des Spezialpapieres, wird, wie bisher gesehen, immer wieder DIN A4 eingestellt. No way !

* * * *

Eingebundene Tabellen:

machen spätestens bei einer auswärtigen Installation so richtig Ärger.

Selbst das Vorhandensein der eingebundenen Tabelle im selben Verzeichnis wie die mdb-Datei bringt nichts, da auf geheimnisvolle Weise immer der vollständige Pfad des Rechners, auf dem die Scheisse programmiert wurde, hinterlegt wird. Eine Lösung für dieses Problem kann unter dem Stichwort 'EINGEBUNDENE TABELLE' gefunden werden.