Du suchst eine Auflistung der Versionen von Access.

Von Access gibt es folgende Versionen:

16-Bit-Versionen
1.0 und 1.1 (veröffentlicht 1992/93)
2.0 stabile Version

32-Bit-Versionen
Access 95 (7.0), wenig beliebt, weil buggy
Access 97 (8.0), stabile Version
Access 2000 (9.0), viele Neuerungen
Access 2002 (10.0), Vollversion von Access 2000
Access 2003 (11.0), wenige Neuerungen, stabile Version
Access 2007 (12.0), viele Neuheiten: neues Dateiformat accdb, Ribbons, Navigationsbereich etc.

32+64-Bit-Versionen
Access 2010 (14.0), einige Änderungen: Support-Artikel
Access 2013 (15.0), wenige z.T. gravierende Änderungen: Support-Artikel Technet-Artikel
Access 2016 (16.0), praktisch keine Änderungen
Access 2019 (16.0 weiterhin), ein paar Neuerungen: neue Diagramme, BigInt-Unterstützung etc., Neuerungen in Access 2019
Access 2021 (16.0 weiterhin), ein paar Neuerungen: Suchen/Ersetzen im SQL-Editor etc., Neuerungen in Access 2021

Seit Microsoft primär auf die Mietversion Microsoft 365 (vormals Office 365) setzt, wird v.a. das dazu gehörende Access 365 laufend aktualisiert. Die Kaufversionen (ab 2016) erhalten dann im wesentlichen die bis zu ihrem Erscheinungszeitpunkt in Access 365 durchgeführten Änderungen.

Die beste Übersicht über alle Access-Versionen bietet die Tabelle von FMS.

Welche Access-Version man am Computer hat, sieht man (einigermaßen) im Menüpunkt ?/Info oder im Ribbonpunkt Datei - Hilfe oder Konto.

Download-Adressen zu den wichtigsten Updates findest du in der Linkliste.

nach oben

Du möchtest eine Datenbank in eine andere Version konvertieren.

Datenbanken im Format einer neueren Version können nicht mit einer älteren Access-Version geöffnet werden (keine Abwärtskompatibilität). Das gleiche gilt für einzelne Objekte einer Datenbank.

Hingegen sind alle Access-Versionen (mit Einschränkungen) aufwärtskompatibel. Mit älteren Access-Versionen erstellte Dateien können 2-3 Generationen lang mit der neueren Version weiterverwendet bzw. konvertiert werden. Die Konvertierung erfolgt automatisch (mit einem warnenden Dialog) beim Start der mdb/accdb mit einer höheren Version oder über einen Menü/Backstage-Ribbon-Punkt in der neueren Version.

Wenn das Konvertieren nicht mehr angeboten wird, weil das Format der Quelldatenbank zu alt ist, kann man versuchen, eine Datenbank im neuen Format anzulegen und über den Menüpunkt Datei/Importieren oder den Ribbonbefehl Externe Daten/Importieren/Access alle Objekte aus der alten Quelldatenbank zu importieren. Das klappt in manchen Konstellationen.

Nach dem Hoch-Konvertieren muss man den Code sorgfältig auf unzureichend konvertierte Teile prüfen, d.h. im VBA-Editor den Menüpunkt Debuggen/Kompilieren aufrufen. Dann werden die fehlerhaften Teile angemeckert, s.a. die Tipps in Konvertieren klappt nicht.

In allen Versionen ab Access 2000 gibt es Menü/Ribbon-Punkte, mit denen man Datenbanken in ältere Formate zurückkonvertieren kann. Das klappt oft, aber nicht immer. Besonders wenn in der neuen Version Features genutzt werden, die es im alten Zielformat noch nicht gibt, verhalten sich betroffene Objekte oft seltsam, sie lassen sich nicht öffnen, die DB oder Access stürzt ab. Nach dem Runterkonvertieren ist also eine sorgfältige Prüfung aller Objekte angesagt.

Zu weniger Problemen kommt es, wenn man die Datenbank von vornherein in einem älteren Format erzeugt oder belässt und sie mit der neueren Access-Version betreibt. Das geht in allen aktuellen Access-Versionen mit 2-3 Generationen älteren Formaten.

Eine Besonderheit gibt es diesbez. Für die Versionen 2007 bis A2021. Hier behauptet MS, es würde das gleiche Dateiformat für alle Versionen verwendet. Das stimmt nur zum Teil. Auch hier gilt: Wenn die Datenbank mit verschiedenen Access-Versionen betrieben werden soll, sollte man darauf achten, keine Features zu verwenden, die es in der älteren Version noch nicht gibt.

nach oben

Du möchtest eine Access-Datenbank an Anwender weitergeben, die kein Access besitzen.

Ausführbare Datei aus einer Access-Datenbank erzeugen geht nicht.
Alle Datenbankdateien von Access (egal ob accdb, mdb, accde, mde etc.) brauchen immer eine Version von Access, d.h. der msaccess.exe, um als Anwendung ausgeführt werden zu können.

Für die Weitergabe an Nicht-Access-Besitzer gibt es bis zur Version 2002/XP eine spezielle Access- bzw. Office-Version für Entwickler, die getrennt zu kaufen ist. Für die Version 2003 gibt es keine spezielle Office-Version sondern ein Paket namens "Visual Studio Tools for the Microsoft Office System". Damit erwirbt man von MS das Recht der unbegrenzten Weitergabe seiner Access-Anwendungen mit der dazugehörigen Laufzeitversion (Runtime).

Für Access 2007 sind sowohl die "Access Developer Extensions" zum Erzeugen von Installer-Paketen als auch die Runtime selber kostenlos bei MS als Download verfügbar. Mit Access 2010 fallen die Developer Extensions weg, Verpackungsassistent etc. sind direkt in Access 2010 enthalten, die Runtime ist gratis. Ab Access 2013 gibt es keinen Verpackungsassistenten mehr.

Die Runtime ist eine modifizierte Version von Access, die für das Laufen der Datenbanken sorgt, in der aber manche Dinge fehlen, z.B. sind keine Entwurfsansichten und keine Standard-Menüleisten verfügbar (s.a. Bereitstellen einer Access-Anwendung). Manche Entwickler verwenden zusätzliche Tools, s. Alternative Setup-Programme.

Bezeichnungen der Entwickler-Versionen:
A2 --> Access Developer's Toolkit (ADT) für A2
A95 --> Access Developer's Toolkit (ADT) für A95
A97 --> Office Developer's Edition (ODE)
A00 --> Microsoft Office Developer (MOD)
AX --> Office XP Developer
A03 --> Access 2003 Developer Extensions (enthalten in den Visual Studio Tools for the Microsoft Office System, manchmal auch: Microsoft Visual Studio Tools for Office 2003)
A07 --> Access Developer Extensions und kostenlose Runtime 2007

Ab Access 2010 gibt es keine Developer-Editionen von Access mehr. Dafür sind die Runtime-Versionen alle kostenlos. Downloadadressen s. Links

Ältere Versionen dieser Pakete sind meist nur noch im Gebrauchthandel zu bekommen, z.B. bei http://www.2ndsoft.de.

nach oben

Du suchst Angaben zur maximalen Größe oder Anzahl von irgendwas mit/in Access.

Auf der Spezifikationen-Webseite von Microsoft gibt es Auflistungen der Größenangaben für DBs, Tabellen, Formulare etc. Hier die wichtigsten mit Anmerkungen, wie sie i.d.R. gefragt werden und die Webseite sie z.T. nicht bietet:

Maximale Größe einer Datenbank
A00 - A21 = 2 GB
Durch das Auslagern von Tabellen und das Einbinden derselben kann man diese Größenlimits umgehen.

Maximale Größe einer Tabelle
A00 - A21 = 2 GB
Es gibt keine maximale Anzahl von Datensätzen sondern nur diese Begrenzung der Speichergröße.
Andere wichtige Maximalgrenzen pro Tabelle: 255 Felder, 32 Indizes, 2000 Zeichen pro Datensatz (ausgenommen sind dabei Felder vom Typ Memo und OLE). Ab A00 gibt es für Textfelder die Eigenschaft "Unicode-Kompression". Wenn sie aktiviert ist, verträgt ein Datensatz ca. 4000 Zeichen.

Maximale Anzahl von Steuerelementen in Formularen und Berichten
A2 - A21 = lt. Dokumentation 754 Stück, wobei nicht nur Steuerelemente sondern auch die Bereiche und die Felder der Datenquelle mitgezählt werden.
Tests haben in verschiedenen Access-Versionen eine höhere Anzahl ergeben, z.B.
A00 = 801
AX+A03 = 895

Maximale Anzahl von Zeilen in Listen- und Kombinationsfeldern
A2 - A21 = 65536

Maximale Anzahl gleichzeitiger User im Netz
A2 - A21 = 255
Diese Zahl ist eher theoretischer Natur. Durch den Fileserver-Charakter von Access ist die tatsächlich mit brauchbarer Performance machbare Anzahl wesentlich geringer. Genaue Zahl lässt sich nicht nennen, da von vielen Faktoren abhängig (v.a. DB-Design, Qualität des Netzes, Organisation der Zugriffe). Die häufigsten genannten Zahlen liegen zw. 5 und 25. Es gibt aber auch Berichte von funktionierenden Access-DBs mit 100 Usern.

nach oben

Du weißt nicht, worauf du achten musst, wenn du für Objekte, Felder oder Variablen deine eigenen Namen vergibst.

Es gibt anerkannte Namenskonventionen für Access und VBA bekannt als "Leszynski/Reddick" bzw. "L/R". Die aktuellen Versionen von Gregory Reddick gibt es bei www.xoc.net.
Das wichtigste Merkmal dieser Konventionen ist die Verwendung der sog. "Hungarian Notation" d.h. es werden Vorsilben verwendet, die sofort erkennen lassen, um welche Art von Objekt es sich handelt. z.B. frmArtikel, tblKunden usw.

Diese Namenskonventionen sind empfehlenswert, aber natürlich nicht verpflichtend. Die meisten Anwender und viele Programmierer verwenden eigene Bezeichnungen. Dabei ist es von Vorteil, zumindest konsistente Benamsungen zu vergeben, d.h. nachvollziehbare Regeln anzuwenden, damit du und andere auch nach einiger Zeit noch wissen, was gemeint ist.

Häufige Fehlerquellen:

Wenn du in Objekt- oder Feldnamen Sonder- oder Leerzeichen verwendest, dann bist du gezwungen, bei jedem Bezug darauf den Namen in eckige Klammern zu setzen. Das kannst du dir sparen bzw. Access machen lassen, indem du Sonderzeichen (wie z.B. Bindestriche) vermeidest und statt Leerzeichen den Unterstrich _ verwendest.

Von Access oder VBA reservierte Schlüsselwörter solltest du nicht für eigene Benamsungen verwenden. Fehler in berechneten Feldern, Ausdrücken und v.a. VBA sind sonst vorprogrammiert, weil Access nicht immer zwischen dem Objekt- oder Feldnamen und dem Schlüsselwort unterscheiden kann.

Der häufigste Fehler in diese Richtung ist die Verwendung der Bezeichnung Name für ein Tabellenfeld. Name ist in Access eine Eigenschaft, nämlich die Bezeichnung eines Objektes. (Außerdem auch noch ein Befehl zum Umbenennen von Dateien.) Also verwende "Nachname", "Firmenname" etc. für deine Felder. Ebenfalls beliebt sind Anzahl = gibt die Anzahl der Steuerelemente in einem Objekt zurück, Wert = Eigenschaft und Funktion oder Tag = engl. Bezeichnung der Eigenschaft Marke. Weitere Hinweise zu dem Thema gibt es in der Online-Hilfe unter: "Benennungskonventionen" und "Richtlinien zum Benennen von ..."

nach oben

Du möchtest, dass beim Start der Datenbank irgendetwas automatisch ausgeführt oder geöffnet wird.

Methode 1

Im Menüpunkt Extras/Start (A95-A03) bzw. in den Access-Optionen unter Aktuelle Datenbank/Anwendungsoptionen (ab A07) können verschiedene Einstellungen für das Aussehen des Access-Fensters, den Titel der DB, die Spezialtasten, das Startformular (Formular anzeigen) etc. getroffen werden.

Zum Ausführen von weiteren VBA- oder Makroaktionen kann man diese z.B. im Öffnen-Ereignis des eingetragenen Startformulares aufrufen.

Methode 2

Man kann ein Makro mit dem Namen Autoexec anlegen. Dieses Makro wird bei jedem Start der Datenbank von Access gesucht und falls vorhanden automatisch ausgeführt. Alles, was beim Start stattfinden soll, wird als Makroaktion eingetragen.

nach oben

Du hast in einem Autoexec-Makro oder in den Startoptionen eingestellt, dass automatisch ein Formular geöffnet wird, Standardsymbolleisten/ribbons und Access-Spezialtasten (und damit <F11> für Datenbankfenster) deaktiviert. Nun kommst du nicht mehr an das Datenbankfenster oder den Navigationsbereich und an deine Entwürfe heran.

Halte beim Öffnen der Datenbank <Shift> (Umschalt-Taste) gedrückt, dann werden Autoexec-Makro und Starteinstellungen nicht ausgeführt.

nach oben

Der Anwender umgeht deine Starteinstellungen, indem er <Shift> beim Öffnen der Datenbank gedrückt hält.

Zum Verhindern der Shift-Tasten-Wirkung gibt es die Eigenschaft AllowBypassKey (s. Online-Hilfe).
Du kannst diese Eigenschaft z.B. mit folgender Prozedur einstellen:

'************* CODE START *************
Sub EnableShift(blnFlag As Boolean)

    On Error GoTo Error_EnableShift

    Dim db As DAO.Database
    Dim prp As DAO.Property

    Set db = CurrentDb
    'Property mit übergebenem Parameter belegen
    db.Properties!AllowBypassKey = blnFlag

Exit_EnableShift:
    Set prp = Nothing
    Exit Sub

Error_EnableShift:

    'Property erzeugen, falls noch nicht vorhanden
    If Err = 3270 Then
        Set prp = db.CreateProperty("AllowBypassKey", dbBoolean, blnFlag)
        db.Properties.Append prp
        Resume Next
    Else
        MsgBox "Ausnahme Nr. " & Str(Err.Number) & " " & Err.Description
        Resume Exit_EnableShift
    End If

End Sub
'************* CODE ENDE *************

Aufruf zum Verhindern der Shift-Taste: EnableShift(False)
Aufruf zum Ermöglichen der Shift-Taste: EnableShift(True)

Wo die Prozedur in der DB aufgerufen wird, ist ziemlich wurscht. Sobald sie ein einziges Mal aufgerufen wurde, wird die Eigenschaft AllowBypassKey dauerhaft für diese DB gesetzt - bis zum nächsten ausdrücklichen Umsetzen. Du kannst also ein beliebiges Ereignis dafür verwenden oder sogar das Testfenster.

Achte darauf, dass du dir in deiner Datenbank eine versteckte Möglichkeit schaffst, auf True zu setzen, damit du selber wieder an deine Entwürfe kommst. (z.B. Umsetzen bei Klick auf ein unauffälliges Bezeichnungsfeld o.ä.)

AllowBypassKey kann ohne Aktivierung des Access-Sicherheitssystems mit mittleren Programmierkenntnissen von außen umgesetzt werden. Wenn das Sicherheitssystem aktiviert ist (s. Anwenden des Sicherheitssystems), lässt sich jedoch einstellen, dass nur der die Eigenschaft umsetzen kann, der die entsprechenden Rechte besitzt. Dazu kann man bei der CreateProperty-Methode den Parameter DDL auf True setzen. (s. <F1> zu CreateProperty) Im konkreten Beispiel:

db.Properties.Append db.CreateProperty("AllowBypassKey", dbBoolean, blnFlag, True)

nach oben

Du möchtest, dass während des Starts einer Anwendung nicht der Bildschirm mit dem MS-Access-Logo erscheint, sondern ein selbst definiertes Bild.

Speichere das gewünschte Bild im Bitmap-Format im gleichen Verzeichnis wie deine mdb/accdb. Gib diesem Bitmap den gleichen Namen wie deiner Datenbankdatei (Extension natürlich auf BMP belassen). Beim Start erscheint nun dieses Bild statt des Access-Logos.

Wenn du ein Bild mit der Größe von einem einzigen Pixel verwendest, dann sieht es aus, als gäbe es gar keinen Startbildschirm.

Wenn die Anwendung über eine Verknüpfung gestartet wird, kommt es vor, dass statt des eigenen BMP der Standard-Begrüßungsbildschirm von Access erscheint. Ursache und Konstellation lassen sich nicht eindeutig festmachen. Versuche dann bei der Verknüpfung nicht nur Pfad und Name der Datenbankdatei anzugeben, sondern auch den Pfad zur msaccess.exe. Also sowas wie
c:\...\Office\msaccess.exe "c:\...\Test.mdb"

Das angeführte Vorgehen verhindert zwar den Access-Begrüßungsbildschirm, moderne Computer sind aber zu schnell, um auf diese Art ein eigenes Logo gut sichbar zu präsentieren. Dafür sollte man eher ein Formular mit einem Bild-Steuerelement verwenden, das sich evtl. durch einen Timer (s. <F1>) gesteuert wieder schließt. Eine andere Variante ist, im Access-Hauptfenster per API ein Bild zu zeigen: http://www.mvps.org/access/api/api0035.htm

nach oben

Du möchtest, dass deine DB (bzw. Access) immer maximiert d.h. als Vollbild geöffnet wird.

Wenn du die DB über eine Verknüpfung startest, dann kannst du in deren Eigenschaften Ausführen auf Vollbild einstellen.

Ansonsten kannst du in deinem Autoexec-Makro oder beim Öffnen deines Startformulares folgenden Code verwenden: RunCommand acCmdAppMaximize

Die gleichen Vorgehensweisen funktionieren auch für Minimieren und Wiederherstellen. Die entsprechenden RunCommand-Konstanten heißen acCmdAppMinimize und acCmdAppRestore.

mein deutscher KB-Artikel dazu im Webarchiv

nach oben

Du möchtest, dass beim Starten einer Access-DB das Access-Hauptfenster nicht angezeigt wird. Der User soll also nur Formulare sehen.

Das wirklich komplette Ausblenden geht mit API.
Im Deklarationsbereich des Formularmodules in deinem Übersichtsformular:

Const SW_HIDE = 0
Const SW_NORMAL = 1

Private Declare Function ShowWindow Lib "user32" _
    (ByVal hwnd As Long, ByVal nCmdShow As Long) As Long

In der Öffnen-Sub deines Übersichtsformulares:

Dim hWindow As Long
Dim nResult As Long
Dim nCmdShow As Long
hWindow = Application.hWndAccessApp
nCmdShow = SW_HIDE
nResult = ShowWindow(ByVal hWindow, ByVal nCmdShow)
Call ShowWindow(Me.hWnd, SW_NORMAL)

In diesem Übersichtsformular musst du auch dafür sorgen, dass Access später mit Quit-Befehl ordentlich beendet wird. Alle Formulare deiner Anwendung müssen auf Pop-Up eingestellt sein, weil sie sonst im nicht mehr sichtbaren Access-Fenster dargestellt werden und daher selber nicht mehr sichtbar sind. Beim Öffnen von Berichten in Seitenansicht muss man die (PopUP-)Formulare alle auf unsichtbar setzen oder schließen.

Hinweis:
Für ein, zwei Formulare, die irgendetwas steuern etc. ist das API-mäßige komplette Verstecken des Access-Fensters u. U. die richtige Lösung. Für eine ausgewachsene Applikation würde ich es aber nicht verwenden. In erster Linie weil in der Taskleiste nix mehr zu sehen ist und der User i.d.R. das Gefühl eines "normalen" Windows-Fenster-Handlings haben sollte. Ich benutze deshalb eher die klassischen Möglichkeiten: eigene Menüleisten, Ausblenden des Datenbankfensters/Navigationsbereiches, evtl. Formulare ohne Rahmen etc.

mein deutscher KB-Artikel dazu im Webarchiv

nach oben

Du möchtest verhindern, dass der Benutzer "unkontrolliert" die aktuelle Datenbank bzw. Access schließen kann, indem er z.B. das Schließen-Symbol im Access-Fenster wählt oder <ALT> + <F4> drückt.

Öffne beim Start der Datenbank (per Autoexec-Makro oder VBA) ein unsichtbares Formular. Im Makro Fenstermodus auf "ausgeblendet" oder per VBA:

DoCmd.OpenForm "DeinFormular", , , , , acHidden
Dieses Formular bleibt die ganze Zeit geöffnet.

Im Formular erstellst du ein Kontrollkästchen z.B. "chkErlaubt", dessen Standardwert du auf Falsch setzt.
Im Ereignis Beim Entladen des Formulares schreibst du:
If Me!chkErlaubt = False Then Cancel = True
Dieses Abbrechen des Entladens verhindert das Schließen der Datenbank und von Access.

Wenn die Bedingung zum Schließen der Datenbank erfüllt ist, setzt du das Kontrollkästchen auf Wahr:
Forms!DeinFormular!chkErlaubt = True
Damit kann das unsichtbare Formular entladen und die Datenbank bzw. Access geschlossen werden.

mein deutscher KB-Artikel dazu im Webarchiv

nach oben

Du möchtest aus einer Access-Datenbank heraus programmatorisch (d.h. nicht per Menüauswahl) eine andere Access-Datenbank öffnen und die aktuelle schließen.

Die einfache Variante geht davon aus, dass eine zweite Instanz von Access kein Problem ist. Der Code dafür könnte z.B. so aussehen:

Shell "C:\Foo\Office\MSAccess.exe C:\Foo\Bar\Meine.mdb", vbNormalFocus  'öffnet and. DB mit Fokus
DoCmd.Quit  'beendet aktuelle Instanz von Access

Schwieriger ist der Wechsel in der gleichen Access-Instanz wie er manuell mit dem Menüpunkt Datei/Datenbank öffnen möglich ist. Es gäbe die Möglichkeit, diesen Menübefehl mithilfe einer Sendkeys-Anweisung auszuführen. Das ist aber nicht empfehlenswert. s. Numlock-Taste (Sendkeys)
Besser, wenn auch aufwendiger, ist die Verwendung eines Add-Ins wie z.B. des TSI SOON bei http://www.trigeminal.com/utility.asp

nach oben

Du möchtest aus der aktuellen DB heraus Objekte einer anderen mdb öffnen bzw. ausführen.

Für einzelne Objekte aus anderen mdbs (mit Einschränkungen):
In den anderen Datenbanken schreibst du in Standardmodule (jene, die im Datenbankfenster sichtbar sind) Funktionen, die die gewünschten Objekte öffnen bzw. ausführen.

In der aufrufenden Datenbank gehst du in einem Modul zum Menüpunkt Extras/Verweise. Dort wählst du mit Durchsuchen die entsprechenden mdbs aus, auf die du zugreifen möchtest.

Wenn der Verweis auf eine andere mdb gesetzt ist, kannst du auf deren Funktionen zugreifen, als stünden sie in der aktuellen mdb.

Beispiele s. mein deutscher KB-Artikel dazu im Webarchiv

nach oben

Du möchtest selbstdefinierte Symbol/Menüleisten oder Import/Exportspezifikationen in eine andere mdb oder accdb übernehmen und findest keine Menüoption oder dergl.

Das geht ganz einfach über das Import-Dialogfenster, nur sind diese wichtigen Optionen etwas versteckt. In der mdb, in die du die Leisten oder Spezifikationen übernehmen willst, wähle Menü Datei/Externe Daten/Importieren und dort die entsprechende Quelldatenbank. Im Import-Dialogfenster zur Auswahl der Objekte wähle die Schaltfläche Optionen>>, die das Dialogfenster erweitert. Dort kannst du nun anhaken, dass die o.a. Dinge mit importiert werden. Auch wenn du keine anderen Datenbankobjekte zum Import auswählst, reicht der Klick auf OK, um Leisten oder Spezifikationen zu übernehmen.

nach oben

Du hast versehentlich eine Tabelle (oder Datensätze) oder ein Formular etc. gelöscht und möchtest es wiederherstellen.

Die Möglichkeiten sind beschränkt. So banal es klingt, ist die beste Möglichkeit, die Benützung einer Sicherheitskopie (zumindest beim nächsten Mal ;-). Gerade bei Datenbanken sollte man für ein ordentliches Backup-System sorgen. Ansonsten hängt es vom Zeitpunkt und vom Zustand der Datenbank ab:

Wenn du sofort nach dem Löschen den Irrtum bemerkst, kannst du mit dem Befehl Rückgängig aus dem Menü Bearbeiten (bzw. der Schaltfläche in der Symbolleiste oder der Tastenkombination <STRG>+<Z>) die letzte Löschaktion rückgängig machen. Das ist aber nur bei Tabellen, Abfragen und Makros möglich, nicht bei anderen Objekten.

Wenn es um gelöschte Tabellen geht und die Datenbank noch nicht geschlossen oder komprimiert wurde, gibt es i.d.R. die Möglichkeit, die letzte gelöschte Tabelle wiederherzustellen:
https://web.archive.org/web/20150219184324/http://support.microsoft.com/kb/179161

Bei anderen Objekten, gelöschten Datensätzen, oder wenn die Datenbank schon geschlossen wurde, sieht es schlecht aus. Solange die Datenbank noch nicht komprimiert wurde, befinden sich die Objekte zwar noch im Datenbankcontainer, sind jedoch nur mehr schwer zugänglich:
<https://web.archive.org/web/20140922043705/http://support.microsoft.com/kb/90129">https://web.archive.org/web/20140922043705/http://support.microsoft.com/kb/90129</a>

In einigen Fällen ist es möglich, solche Inhalte oder Objekte wieder herzustellen, dazu ist jedoch eine genaue Kenntnis der inneren Struktur von Access nötig. Bei Verlust von wertvollen Daten kannst du versuchen, dich an einen kommerziellen (Access-)Datenretter zu wenden. s. Links

Falls die Datenbank nach dem Löschen bereits komprimiert wurde, bleibt nur die Neuerstellung der Objekte oder Neueingabe der Daten.

nach oben

Du möchtest wissen, wie sicher dein Code, deine Objekte und deine Daten sind, wenn du sie mit den Methoden schützt, die Access anbietet.

Zuerst möchte ich bemerken, dass ich über diese Infos hinaus nichts weiter "preisgebe" und auch keine Access-mdbs kommerziell knacke oder dergl. Es ist also sinnlos, weiter nachzufragen.
Wenn du der rechtmäßige Eigentümer einer DB bist (und das beweisen kannst) und du kommst aus irgendwelchen Gründen nicht mehr in die DB, dann kannst du dich mit dem Problem an einen professionellen Datenretter wenden. s. Links

Generell gilt m.E. dass man bei Berücksichtigung des relativ niedrigen Preises von Access nicht sehr viel erwarten kann und dafür die Möglichkeiten gar nicht so schlecht sind. Wenn du wirklich hochsensible Daten hast oder sonst. extreme Sicherheitsbedürfnisse, dann solltest du ein teureres Datenbanksystem verwenden, das dann auch noch höhere Sicherheit bietet als Access z.B. MS-SQL-Server, Oracle etc.

Zwei sinnvolle Varianten, um eine Access-DB zu sichern:

ACCDE
Es gibt die Möglichkeit, ACCDBs in ACCDEs umzuwandeln (im älteren Format MDB --> MDE). Der komplette Code und die Entwürfe von Formularen und Berichten sind in einer ACCDE relativ gut aufgehoben. s.a. https://support.office.com/article/CE6AB610-AF07-4008-91E0-1EF1B796FF18
Eine ACCDE enthält keinen Code in Textform mehr sondern nur in kompilierter Form. Eine Dekompilierung d.h. Wiedergewinnung des Codes ist schwierig. s. FAQ 1.26

Datenbankkennwort
Das Datenbankkennwort (https://support.office.com/article/12aa0e5c-34c6-4957-af3b-b5f5cfa9a766) ist in Versionen ab Access 2007 für die üblichen Knackprogramme nur mit Brute-Force-Methoden zu knacken (in Versionen vor 2007 ist es unsicher). Ausreichend lange Kennwörter mit gemischten Zeichen sind daher ein brauchbarer Schutz für eine Access-Datei. Wichtig ist, dass sowohl Backend als auch Frontend mit DB-Kennwörtern gesichert sind, also die Dateikette geschlossen ist, denn Tabellenverknüpfungen aus anderen DBs enthalten deren DB-Kennwort im Klartext.

nach oben

Du möchtest das Sicherheitssystem von Access verwenden, also Benutzerrechte und Passwörter vergeben etc. Dabei stößt du auf Schwierigkeiten und findest keine brauchbare Anleitung.

Access-Versionen bis 2003 bieten die Möglichkeit, Rechte auf Benutzerebene zu vergeben. Mit Access 2007 hat Microsoft diese Technik abgeschafft, da sie leicht zu knacken war.

Die Beschreibung in diesem Artikel ist daher gelöscht und der Artikel geht bald in Rente.

nach oben

Du möchtest wissen, ob es gefahrlos möglich ist, eine Datenbank mit einer deutschen Access-Version zu erstellen, wenn sie anschließend mit einem andersprachigen Access laufen soll bzw. hast es schon versucht und feststellen müssen, dass an vielen Stellen unerklärliche Fehlermeldungen kommen.

Die sicherste Methode ist, die Anwendung mit Access und Windows in der Sprache zu erstellen oder zumindest umfangreich zu testen, in der sie laufen soll. Nach meiner Erfahrung ist es zumindest für europäische Sprachen so, dass eine Anwendung, die im englischen Access läuft, auch in den anderen Sprachen funktioniert.

Wenn mit einem deutschen Access entwickelt wurde:
Ein häufiger Fehler ist, dass der Eintrag "[Ereignisprozedur]" in Formular- und Berichts-Ereigniseigenschaften nicht immer übersetzt wird. Das führt z.B. in einem engl. Access zum Fehler "Can't find macro '[Ereignisprozedur]'..." weil dort eigentlich "Event Procedure" stehen sollte. Das musst du dann händisch nachbessern oder Code verwenden, der die Objekte in der Entwurfsansicht öffnet und den Text ersetzt.

Achte darauf, dass du in Abfragen bei Formularbezügen immer das englische Forms!... verwendest statt des deutschen Formulare!... ansonsten gibt's eine Aufforderung "Enter Parameter Formulare!...".
Weitere Probleme können z.B. durch Währungssymbole verursacht werden, durch "deutsche" Datumsformatierungen etc.

Deshalb noch einmal der Rat, mit englischsprachigem Access zu entwickeln bzw. vor dem Ausliefern ausführlich damit zu testen.

nach oben

Du möchtest eine mdb nach Visual Basic konvertieren.

Es gibt kommerzielle Tools wie z.B.
AccessToVB http://www.GFMinc.com, http://www.accesstovb.de/
Access Converter http://www.diamondedge.com/products/Convert-Access-to-VB.html

Es gibt noch einige andere Tools und die Links wechseln häufig. Also am besten eine Suchmaschine anwerfen mit Stichworten wie: "Converter Access VB"

Eine vollwertige Konvertierung bzw. Übernahme aller Access-Funktionalitäten nach VB ist aber auch mit diesen Tools nicht möglich.

nach oben

Du möchtest ein Objekt löschen, das sich in einer anderen Datenbank befindet.

Für Tabellen und Abfragen ist der (Lösch-)Zugriff ohne viel Aufwand per DAO (oder ADO) möglich. z.B.

Dim db As DAO.Database
Set db = DBEngine.Workspaces(0).OpenDatabase("c:\...\DieAndere.mdb")
db.Tabledefs.Delete "DeineTabelle"
'oder db.QueryDefs.Delete "DeineAbfrage"
db.Close
Set db = Nothing

Für andere Objekte braucht man etwas Automatisierungs-Code z.B.:

'neue Access-Instanz öffnen
Dim appAcc As Access.Application
Set appAcc = New Access.Application

'andere DB öffnen und Objekt löschen
appAcc.OpenCurrentDatabase "c:\...\DieAndere.mdb"
appAcc.DoCmd.DeleteObject acReport, "BerichtsName"

' und weg
appAcc.Quit
Set appAcc = Nothing

nach oben

Die Größe deiner mdb-Datei nimmt während der Erstellung oder Benützung unverhältnismäßig zum Datenzuwachs zu.

Gelöschte Objekte oder Daten werden zwar nicht mehr angezeigt, aber von Access nur als gelöscht markiert. Erst bei einer Komprimierung werden sie tatsächlich aus der Datei entfernt. Besonders stark wirkt sich das während Arbeiten am Design der Objekte oder bei der Verwendung von temporären Tabellen etc. aus.

Möglicherweise speicherst du auch Bilder direkt in der mdb.
Eine andere Ursache können schlecht kompilierte Codeteile sein, die als überflüssiges Kompilat im Datenbank-Container liegen bleiben.

Selbst zur Laufzeit, also wenn keine Änderungen an der Struktur mehr vorgenommen werden (auch in einer ACCDE), kann die Datei noch wachsen z.B. durch das Ausführen (und interne temporäre Speichern) von SQL-Statements, die Datenherkunft von Formularen oder Berichten sind. Weitere Ursache können Access-Bugs sein, die bewirken, dass der Speicher von Recordsets nicht freigeben wird (s.a. Access lässt sich nicht beenden) und gespeicherte Abfragen immer wieder kompiliert werden.

Komprimiere die Datenbank.
Ribbon: Datenbanktools/Datenbank komprimieren und reparieren
(Die Option "Datenbank beim Schließen komprimieren" ist mit etwas Vorsicht zu genießen, da sie in manchen Situationen zu Korruptionen oder Datenverlust führen kann.)

Wenn das nichts oder wenig bringt, dann erzeuge eine neue Datenbank und importiere alle Objekte der alten Datenbank in diese neue.

Eine weitere Möglichkeit ist die Befehlszeilenoption decompile.

nach oben

Du möchtest mehr über diese (fast) undokumentierte Befehlszeilenoption wissen, die bei versch. Problemen helfen kann, die mit korrupten Code-Containern zusammenhängen.
Symptome können z.B. unverhältnismäßige Größe der Datenbankdatei sein oder viele Arten von unerklärlichen Fehlermeldungen oder Abstürzen von Access.

Erstelle eine Verknüpfung zu der ACCDB-Datei und gib in den Eigenschaften dieser Verknüpfung unter Ziel den Pfad zu Access, den Schalter und dann erst Pfad und Name der ACCDB ein z.B.

"c:\Pfad\msaccess.exe" /decompile "c:\Pfad\Deine.accdb"

Dann starte die Datenbank über diese Verknüpfung. Danach sollte die Datenbank komprimiert werden.

Achtung!
Decompile ist undokumentiert und mit etwas Vorsicht zu genießen.
Es wurden öfter Probleme damit gemeldet. z.B. kam es vor, dass nach der Verwendung von decompile benutzerdefinierte Klassenmodule nur mehr wie Standardmodule behandelt wurden.

Sicherer ist es daher, decompile nur auf eine Kopie der Datenbank anzuwenden und diese anschließend zu testen.

Eine genauere Beschreibung gibt es von Michael Kaplan:
http://www.trigeminal.com/usenet/usenet004.asp

nach oben

Du suchst Such- oder Analysetools für Access.

Tools zum globalen Suchen und Ersetzen in Access:

Find And Replace for Microsoft Access AccessDevTools, kommerzielles Add-In mit 30 Tage Testversion
https://accessdevtools.com/product/find-and-replace/

V-Tools Gratis-Tool mit Suchfunktion und anderen Tools
https://www.skrol29.com/us/vtools.php


Tools zum Analysieren von Datenbanken:

Generell empfehlenswert, aber nicht ganz billig, sind die Developer oder Enterprise Suite von FMS, zum Analysieren speziell der
Total Access Analyzer http://www.fmsinc.com.

Vergleichen von Datenbanken:

Total Access Detective (für Objekte, Code und Daten)
http://fmsinc.com/products/detective/

nach oben

Du suchst "gute" Bücher zu Access, VBA, Datenbanktheorie, SQL, API oder sonst einem Thema im Zusammenhang mit Access und wunderst dich, dass es hier keine Buchseite gibt.

Es gibt hunderte von Büchern zu den o.a. Themen und zu vielen davon habe ich eine Meinung. Ich bin aber grundsätzlich der Ansicht, dass Buchempfehlungen nur Sinn machen, wenn ein Werk einzigartig in seiner "Gewichtsklasse" ist.

Ansonsten ist das eine extrem subjektive Sache. Ob du mit einem Buch etwas anfangen kannst, hängt zumindest ab von deinen Vorkenntnissen, deiner Art zu lesen und zu lernen, deinen bevorzugten Ordnungs-/Gliederungskriterien, deinen Sprachkenntnissen und natürlich deinen Absichten.

Ich empfehle daher:
Als Orientierungshilfe, welche Bücher zu bestimmten Themen existieren, kannst du zuerst mal in einem der Online-Buchläden (Amazon etc.) suchen. Sei skeptisch bei Online-Empfehlungen (ok, ein bissel paradox;-) und Werbesprüchen oder Klappentexten. Nimm dir daher Zeit und gehe in mehrere gut sortierte Buchläden. Schmökere möglichst ausführlich in allen Büchern, die du zum Thema in die Finger bekommst, und entscheide selbst, was für dich passen könnte.

Ich möchte bloß 3 Bücher empfehlen, die ich wie o.a. für einzigartig in ihrer Klasse halte. Alle 3 sind nur in englisch erhältlich und eher nur für erfahrene Programmierer brauchbar. Sie sind in deutschsprachigen Landen nur selten im konventionellen Buchhandel zu finden.

Access 2002 Developer's Handbook Set
Ken Getz, Paul Litwin, Mike Gunderloy
2480 Seiten, 2002, Sybex, ISBN 978-0782140118

Das ADH ist allg. anerkannt als DIE Access-Programmier-Bibel, großes Nachschlagewerk, viele Lösungen auf CD. Wer professionell mit Access programmiert, sollte es sich besorgen; s.a. Info der Autoren, ADHs gibt's für alle Access-Versionen von 2.0 bis A03.



Microsoft Access Developer's Guide to SQL Server
Mary Chipman, Andy Baron
840 Seiten, 2000, Sams, ISBN 978-0672319440

Wer Erfahrung mit Access hat und sich für den MS SQLServer interessiert, findet hier eine genau darauf ausgerichtete, ausführliche Einführung zum Server und dem Zusammenspiel mit Access (ADPs, ODBC). Darüber hinaus viel zu T-SQL, Views, Stored Procedures, Deployment, Sicherheit, Tools usw.


Designing Relational Database Systems
Rebecca M. Riordan
320 Seiten, 1999, Microsoft Press, ISBN: 978-0735606340

Einführung in die Theorie relationaler Datenbanken, Design der Datenbanken und der Benutzeroberflächen. Alles in Hinblick auf Access und MS-SQL-Server. Man merkt die große praktische Erfahrung. Inhaltlich gibt's ein paar kleine Schwächen, aber ich kenne von den behandelten Themen her aktuell nix Vergleichbares. Relativ hohes englisches Sprachniveau, doch gut und meist sehr klar formuliert

nach oben

Du hast eine ACCDE erstellt (s.a. Wie sicher ist Access?) und die Quell-ACCDB dazu verloren. Jetzt möchtest du die Datenbank wieder in eine ACCDB umwandeln.

Nur die Firma www.everythingaccess.com bietet einen solchen kostenpflichtigen Service an. Sie hat in einem von mir durchgeführten Test bewiesen, dass sie wirklich dazu in der Lage ist. Voraussetzung ist, dass man entsprechende Rechte an der Datenbank nachweisen kann. Details dazu bietet ein Artikel aus Access-im-Unternehmen.

Für eigene Versuche bzw. kostenlose Tools gilt nach wie vor:

Tabellen, Abfragen und die Daten aus den Systemtabellen (Beziehungen, Import/Exportspezifikationen etc.) sind in einer ACCDE (in älteren Versionen MDE) ganz normal zugänglich. An alle Objekte, die Code enthalten können, kommt man nicht mehr direkt heran. Es ist jedoch möglich, mit etwas Code oder entsprechenden Tools, die meisten Informationen, v.a. die Designs aus der ACCDE auszulesen und in einer neuen ACCDB wieder zu verwenden. Der komplette VBA-Code hingegen ist verloren.

Die einfachste und beste Variante bei der Erstellung von ACCDEE-Dateien ist natürlich, eine Reihe von Sicherheitskopien der zugrundeliegenden ACCDB anzulegen und gut aufzuheben.

nach oben

Eine Datenbank lässt sich nicht mehr öffnen. Oder Access stürzt bei einer best. Datenbank immer wieder ab. Oder eine DB verhält sich plötzlich nicht mehr "normal" d.h. Vorgänge, die bisher funktioniert haben, schlagen fehl.

Häufige Ursachen von Defekten sind unsauberes Beenden, Netzwerk- und andere Hardware-Probleme und diverse Bugs von Access oder Windows oder durch Microsoft-Updates.

Es gibt etliche Formen vom leichten Defekt bis zur schweren Korruption. Deshalb gibt's auch viele Lösungen.

Wichtig: Bei allen Reparatur-Maßnahmen und -Versuchen solltest du nur mit einer Kopie der ACCDB/MDB-Datei arbeiten. So mancher Reparaturversuch kann nämlich die Lage verschlimmern.

Einige Tipps zum Vorgehen (nicht unbedingt in dieser Reihenfolge - hängt von der Art des Fehlers ab):

Information

• Schau dir hier das Kapitel über verschiedene häufige Formen von Access-Bugs an. Vielleicht befindet sich dein persönlicher - und eine Lösung - schon darunter.


• Kontrolliere, ob dein Problem auf der Bugs und Fixes-Webseite für Access beschrieben ist. s. Links


• Frage in einer Newsgroup oder in einem Webforum nach einer Lösung. s. Links

• Versuche eine Reparatur mit Datenbanktools > Datenbank komprimieren & reparieren.


• Erstelle eine neue ACCDB/MDB und versuche, die Objekte der defekten DB in diese neue Datei zu importieren. (Externe Daten > Importieren und Verknüpfen > Access.)


• Falls es VBA-Code in der DB gibt, dann versuche den Schalter Decompile.


• Falls ein bestimmtes Objekt, z.B. ein Formular oder Bericht, offensichtlich korrupt ist, dann versuche seinen Export als Textdatei und anschließenden Reimport. Dafür gibt es die versteckten VBA-Funktionen SaveAsText und LoadFromText:
  
  Export eines Formulares als Textdatei
  Application.SaveAsText acForm, "MeinFormular", "c:\MeinFormular.txt"
  
  Reimport des Formulares
  Application.LoadFromText acForm, "MeinFormular", "c:\MeinFormular.txt"


• Versuche die DB mit einer neueren Access-Version zu öffnen oder in diese zu konvertieren. Manche Fehler werden von einer neueren Version gefixt oder ignoriert.


• Wenn es um Daten geht, kannst du versuchen, per DAO-Programmierung darauf zuzugreifen und die Daten auf diese Art in neue Tabellen bzw. eine neue DB zu kopieren. Der Zugriff per DAO klappt manchmal noch mit Tabellen oder DBs, die über die Benutzeroberfläche nicht mehr zugänglich sind.
  Noch öfter als der DAO-Zugriff klappt der per ODBC. Das geht mit allen Programmen, die mit dem Access-ODBC-Treiber zurecht kommen, z.B. mit MS Query von Excel aus (Access--> Access per ODBC funktioniert übrigens nicht).


• Wenn das alles nichts bringt, kannst du dich noch an eine professionelle Datenrettungsfirma wenden. s. Links
  Diese Firmen können viele Formen von Defekten reparieren bzw. meist die Daten noch retten. Der Service kostet natürlich etwas und es gibt noch andere als die von mir gelinkten Anbieter. Achte jedenfalls darauf, dass die Firma nur im Erfolgsfall das volle Honorar fordert.

nach oben

Du bist unsicher, wann du bei der Verwendung von Funktionen das Komma oder das Semikolon (österr. Beistrich bzw. Strichpunkt) als Trennzeichen für die Argumente verwenden musst, und wirst deshalb von Syntaxfehlermeldungen gejagt.

Grundsätzlich bestimmt das Listentrennzeichen in den Ländereinstellungen bzw. Regions- und Sprachoptionen der Windows-Systemsteuerung, welches Zeichen für die Trennung von Argumenten zuständig ist. In den meisten europäischen Einstellungen (z.B. deutsch, italienisch, französisch, spanisch) ist das standardmäßig das Semikolon. Das betrifft aber nur die "oberflächlichen" Ansichten von Access, während für die grundsätzlich amerikanischen Applikationsteile wie VBA und SQL die amerikanische Einstellung, nämlich das Komma, gilt.

Die Verwendung von Komma oder Semikolon hängt davon ab, wo die Funktion verwendet wird.
Für Ausdrücke an der Access-Benutzeroberfläche z.B. in der Entwurfsansicht von Formularen und Berichten oder im Abfrage-Entwurfsfenster, musst du das Semikolon verwenden. In VBA und in der SQL-Ansicht einer Abfrage hingegen das Komma. Beispiele:

Steuerelementinhalt in einem Formular oder Bericht:
=DLookUp("Feld";"Tabelle";"Bedingung")
Du kannst dort auch die deutsche Version des Funktionsnamens verwenden bzw. übersetzt Access ohnehin automatisch in:
=DomWert("Feld";"Tabelle";"Bedingung")

als Teil einer Prozedur im VBA-Code:
... = DLookUp("Feld","Tabelle","Bedingung")

Ausdruck im Abfrageentwurfsfenster:
Left([Feld];3)
bzw. wieder auf deutsch:
Links([Feld];3)

Wenn du in die SQL-Ansicht der Abfrage wechselst, siehst du hingegen:
Left([Feld],3)

Dieser Unterschied in der Verwendung von , und ; betrifft sowohl alle eingebauten Access- und VBA-Funktionen als auch alle selbst geschriebenen.

nach oben

Du möchtest die Beziehungen der Tabellen, wie sie im Beziehungsfenster sichtbar sind, ausdrucken. Du findest dazu keine Möglichkeit oder Hilfe.

Ab A07 gibt es den Ribbonbefehl Entwurf/Tools/Beziehungsbericht.
In A00-A03 heißt der entsprechende Menüpunkt (bei geöffnetem Beziehungsfenster) Datei/Beziehungen drucken.

Für noch größere Ausdrucke mit A97 und A00 gibt es ein Tool von Stephen Lebans:
http://www.lebans.com/windowtobitmap.htm

Von Stephen Lebans gibt es auch eine Funktion zum Ausdrucken des Beziehungsfensters als PDF. Sie findet sich in der letzten Version seines Tools zur PDF-Erstellung http://www.lebans.com/reporttopdf.htm.
Hinweise zur Benützung (von Sascha Trowitzsch):
Im Modul modReportToPDF ist die Prozedur RelationsToPDF enthalten, die das Beziehungslayout in ein PDF ausgibt. Funktioniert auch unter A07. Der Funktion muss ein Verweis auf ein Label übergeben werden (zwecks Font-Daten). Außerdem ist der Ausgabepfad in der Routine hartkodiert, was man erst ändern muss, bzw. besser gleich als Parameter an die Prozedur gibt. (Nach "C:\sourcecode\ReportToPDF\Relations.pdf" im ellenlangen Code suchen.) Die Größe des Dokumentes wird dem Layout angepasst und es enthält noch Zusatzinfos, wie die Zahl der Datensätze jeder Tabelle.

nach oben

Du suchst Informationen zum Thema Replikation. Die Online-Hilfe ist schnell aufgebraucht.

Replikations-FAQ hervorragend (engl.)
Dort gibt es auch (wechselhafte) Links zu weiteren MS-Quellen v.a. für A97 (engl.)

Einen Überblick gibt der MSDN-Artikel:
Database Replication in Microsoft Jet 4.0 (engl.)

http://www.trigeminal.com die Website von Michael Kaplan (mehrsprachig, auch dt.)
mit vielen Utilities, Tipps, Links, Auflistung aller KB-Artikel zur Replikation u.v.a.

news:microsoft.public.access.replication Newsgroup (engl.)

Literatur zum Thema "Replikation" gibt es leider sehr wenig. Empfehlenswert ist das ausführliche Kapitel zur Replikation in der jeweils passenden Version des Access Developer's Handbook (ADH).

nach oben

Du suchst Information zu Normalformen, Beziehungen oder sonstiger (relationaler) Datenbanktheorie.

Eine gute Einführung in die Theorie (Normalformen, Beziehungen, Schlüssel, SQL etc.) bietet Andreas Kelz: Relationale Datenbanken

Ein Vortragsskript von Michael Zimmermann zum Thema Normalisierung gibt es bei den Downloads der AEK7.

Einen kurzen Überblick über die Normalformen mit Access-Bezug gibt's bei MS:
ACC2000 - Grundlagen der Datenbanknormalisierung
(Die Beschreibung enthält übrigens einen Fehler: "...die vierte Normalform, die auch als Boyce Codd-Normalform (BCNF) bezeichnet wird..." - die 4. NF ist nicht die BCNF)

Eine Schritt-für-Schritt-Anleitung zur Erstellung einer relationalen Datenbank - anhand der bei Access inkludierten Beispiel-DB "Nordwind" - gibt's von MS als Word-doc (englisch):
<https://web.archive.org/web/20150530212148/https://support.microsoft.com/en-us/kb/164172">https://web.archive.org/web/20150530212148/https://support.microsoft.com/en-us/kb/164172</a>

Es gibt noch viele weitere Webseiten zur Datenbanktheorie, allerdings IMO meistens entweder dürftig oder recht akademisch. Also einfach mal bei einer Suchmaschine auf Reisen gehen.

Ebenfalls englisch ist der Literaturtipp zum Thema: Rebecca Riordans Designing Relational Database Systems

nach oben

Du möchtest, dass best. Datenbankobjekte (meist geht's um Tabellen) nicht im Datenbankfenster sichtbar sind.

Eine einfache Lösung ist das manuelle Ausblenden:
Im Navigationsbereich rechter Mausklick auf das Objekt, im Kontextmenü Eigenschaften wählen und dort Ausgeblendet ankreuzen. Die Objekte sind dann nur sichtbar, falls in den Optionen des Navigationsbereiches Ausgeblendete Objekte anzeigen angehakt ist.

Programmatorisch geht das mithilfe der SetHiddenAttribute-Methode z.B.

Application.SetHiddenAttribute acTable, "MeineTabelle", True

s. dazu <F1> im VBE-Editor

Eine Möglichkeit für das Ausblenden von Objekten, die auch in älteren Versionen funktioniert, ist, den Objektnamen mit "usys" beginnen zu lassen. Das ist eine Vorsilbe für Systemobjekte, die standardmäßig nicht angezeigt werden (ebenfalls in den Navigationsoptionen änderbar).

Eine andere Variante ist die Verwendung des Attributes dbHiddenObject. Das kann nur per Code durchgeführt und rückgängig gemacht werden, z.B.

Currentdb.TableDefs("MeineTabelle").Attributes = Currentdb.TableDefs("MeineTabelle").Attibutes + dbHiddenObject

In sehr alten Access-Versionen (bis Access 97) gingen derart versteckte Tabellen beim Komprimieren verloren. Danach noch einige Versionen lang (zumindest bis Access 2010) beim Erstellen einer MDE bzw. ACCDE. Mit Access 365 konnte ich aber auch das nicht mehr nachvollziehen.

nach oben

Du möchtest eigene Menü- und/oder Symbolleisten erstellen oder die eingebauten während der Laufzeit verändern und weißt nicht wie oder hast Probleme dabei.

Das händische Erstellen/Verändern von Symbolleisten ist relativ einfach:
Rechte Maustaste auf eine Menü- oder Symbolleiste, Anpassen im Kontextmenü wählen und dann in diesem Anpassen-Modus herumsuchen und -fuchteln. Umfangreiche Anleitung gibt es in der Online-Hilfe.

Die Programmierung hingegen funktioniert seit A97 über die Commandbars-Auflistung und deren Objekte/Eigenschaften. Die Online-Hilfe bietet viele unübersichtliche Seiten dazu. Darum gibt es ein Whitepaper zur geordneten Übersicht und eine Beispiel-Anwendung "CreativBars" für die allermeisten Anwendungsfälle, beides von Anette Ratjen bei http://www.dbdev.org und http://www.pc-creativ.de.

nach oben

Du hast Probleme mit dem Setup der Office Developer Edition. Entweder schon beim Erstellen der Setups oder beim Installieren der erzeugten Runtime-Pakete.

Die Runtime-Erstellung und -Installation mit dem Setup-Assistenten von A97 bzw. dem Paket- und Weitergabe-Assistenten ab A00 ist leider legendär unzuverlässig und fehleranfällig. Um eine Runtime weiterzugeben, ist unbedingt eine Lizenz der passenden Office Developer Version erforderlich. Man muss aber nicht den mitgelieferten Setup-Ersteller verwenden. Es gibt einige Alternativen dazu:

Inno Setup heißt ein populäres Freeware-Programm für das Anleitungen, Skripte (für A97), Newsgroups usw. frei verfügbar sind. Mithilfe dieser Skripte lassen sich die Probleme der o.a. Assistenten vermeiden.
http://www.jrsoftware.org Inno Homepage
http://www.unofactura.de Bernhard Martins Tipps zu Inno Setup und zu A97-Runtime-Problemen
Inno-Setup + IsTool Vortrag von Michael Reitz bei der 4. AEK

Neben Inno Setup gibt es viele andere Freeware- und Shareware-Installer. Also bei bedarf einfach eine entsprechende Internet-Suche starten.

Kommerzielle Lösungen gibt es z.B. von Installshield und Wise. Für diese beiden Installer bietet die Firma Sagekey relativ teure, aber professionelle und zuverlässige Skripts für alle gängigen Access-Versionen, die wiederum die Fehler und Probleme der Office-Installations-Assistenten vermeiden.
Installation Vortrag (v.a. zu Sagekey-Skripts) von Wolf Kristen bei der 3. AEK

nach oben

Du hast eine Access-Anwendung, die nur aus einer einzigen Datei besteht, also 1 MDB/ACCDB oder MDE/ACCDE. Das verursacht vielfältige Probleme z.B. geht die Datei öfter kaputt, oder sie bläht sich übermäßig auf oder du musst für jede kleine Änderungen die Anwendung sperren.

Access-Anwendungen sollten grundsätzlich aus zwei (oder mehr) Dateien bestehen. Besonders im Mehrbenutzerbetrieb ist eine Aufteilung in Frontend (FE) und Backend (BE) dringend angesagt.
Unter Backend versteht man bei Access eine MDB/ACCDB, die nur die Tabellen enthält. Das Frontend enthält alle anderen Datenbankobjekte (Formulare, Berichte, Abfragen, Makros, Module) und die aus dem Backend eingebundenen Tabellen. Bei Anwendungen im Netzwerk sollte jede Arbeitsstation ihr eigenes, möglichst lokales FE bekommen, während das gemeinsam genutzte BE am Server liegt.

Die Gründe für diese Maßnahmen:
- Ohne Aufteilung in FE und BE kommt es bei Mehrbenutzerzugriff oft zu Beschädigungen der Datei. Bei FE-BE-Aufteilung sind diese Korruptionen wesentlich seltener. Sollte das FE doch einmal kaputt gehen, kann es einfach und ohne Datenverlust ausgetauscht werden.
- Durch lokale FEs gibt es weniger Netzwerkverkehr, weil nur die Daten übers Netz gehen müssen.
- Design-Änderungen sind an einer Frontend-Kopie jederzeit möglich.

Für die Aufteilung in FE und BE liefert Access einen Assistenten (Menü Extras/Datenbank-Dienstprogramme/Assistent zur Datenbankaufteilung bzw. Ribbon Datenbanktools/Daten verschieben/Access-Datenbank). Die Aufteilung ist aber auch ohne Assistent relativ einfach, indem man in eine neue MDB/ACCDB die Tabellen importiert, sie im FE löscht und dann neu einbindet.

Eine Folge der Aufteilung ist die Notwendigkeit, die Tabellen bei geänderten Pfaden neu einzubinden. Auch dafür bietet Access einen Assistenten (Extras/Datenbank-Dienstprogramme/Tabellenverknüpfungs-Manager), alternativ s. Tabellen wieder einbinden.

Zur automatisierten Verteilung der FEs im Netz gibt es kostenlose Frontend-Updater-Tools wie z.B.:
- Application Starter von Peter De Baets http://www.peterssoftware.com/aps.htm
- MDB Loader and Updater rein Access-basiert, von Henry Habermacher, bei den Downloads der www.dbdev.org
- DBUpdate - Frontend Updater mit vielen Zusatzfunktionen, von Gunter Avenius bei www.avenius.com

Ein kostenpflichtiges Tool von Tony Toews: http://autofeupdater.com/

Weitere Informationen dazu bieten die Folien meines Vortrags "Frontend-Updater" bei der AEK8: AEK-Downloads

Ausführlichere Informationen zum kompletten Themenbereich bietet das Whitepaper "Betrieb von Access Anwendungen" von Henry Habermacher bei www.dbdev.org.

nach oben

Du möchtest die ab Access 2007 eingebauten Ribbons (offizielle dt. Bezeichnung in A07 Multifunktionsleiste, in A10 Menüband) individuell anpassen und findest wenige Möglichkeiten und Informationen dazu.

In A07 gibt es als einfache Möglichkeit zur individuellen Anpassung nur die Zuweisung von Ribbons zu bestimmten Formularen oder Berichten. Dies funktioniert über deren Eigenschaft Multifunktionsleiste (in A10 Name des Menübands). Ansonsten bleibt nur die etwas mühsame Programmierung per XML usw.

In A10 hingegen hat MS unter Datei/Optionen/Menüband anpassen eine einfache Möglichkeit geschaffen, die sich allerdings darauf beschränkt, dass man die eingebauten Register, Gruppen und Befehle umordnen, unsichtbar machen usw. kann: http://office.microsoft.com/de-de/access-help/anpassen-des-menubands-HA010355697.aspx

Wer mehr möchte, sollte sich näher mit der Ribbon-Programmierung per XML, Callbacks usw. beschäftigen.
Grundlegende Informationen dazu bietet http://office.microsoft.com/de-de/access-help/anpassen-der-multifunktionsleiste-HA010211415.aspx.

Umfangreiche Informationen und Beispiele zu allen Aspekten des Themas Ribbon bietet Gunter Avenius auf www.AccessRibbon.de.
Vom gleichen Autor gibt es das Tool Ribbon Creator, mit dem man einfach und schnell individuelle Ribbons erstellen kann:
https://www.ribboncreator2016.de/

nach oben