Access-Client-Server

Kann man auch Oracle/MySQL/Sybase/Mein DBMS als Backend für ein ADP verwenden?

Nein, ausschließlich der Microsoft SQL Server bzw. die MSDE (Microsoft Data Engine) wird als Backend für Access Data Projects unterstützt. Kein anderes DBMS wird zur Zeit offiziell unterstützt und es gibt keine Workarounds um ein anderes DBMS als Backend zu verwenden.

Es gibt bisher auch keinerlei Informationen dazu, dass in der Zukunft weitere DBMS als Backend für ADPs unterstützt werden sollen. Da die Integration weiterer DBMS als Backends für ADPs einen erheblichen Aufwand darstellen, insbesondere auch bei der Wartung und Anpassung an neue Versionen, und immer vom Funktionsumfang des jeweiliegen DBMS abhängig ist, ist es meiner Meinung außerordentlich unwahrscheinlich, dass Microsoft jemals das DBMS eines Drittherstellers als Backend für ADPs unterstützen wird.

Wenn mehrere Benutzer die ADP-Datei öffnen, bekommen alle Benutzer nach dem ersten die Meldung 'Die Datenbank 'xyz' wird schreibgeschützt geöffnet...' Was kann man dagegen tun?

Das ist so 'by Design'. Bei einer MDB-Anwendung werden die Informationen, welcher Benutzer welche Objekte bearbeitet und damit sperrt, in der LDB-Datei gespeichert. Dadurch ist es möglich, dass mehrere Benutzer gleichzeitig Schreibzugriff auf ein und dieselbe Datei haben.

Bei einem ADP gibt es keine LDB-Datei, daher muss Access immer davon ausgehen, dass der erste Benutzer, der die Datei öffnet Änderungen an den Objektdefinitionen vornimmt und sperrt die gesammte Datei. Dadurch haben alle weiteren Benutzer nur noch schreibgeschützen Zugriff auf die Datei. Der Schreibschutz gilt nur für die ADP-Datei, d.h. Formulare, Berichte, Module, etc. aber nicht für die Daten auf dem SQL-Server.

Als einfachen Workaround für dieses Problem kann man Access im Runtime-Modus starten und die ADP-Datei öffnen. Im Runtime-Modus kann man sowieso keine Änderungen an den Objektdefinitionen vornehmen, daher unterbleibt in diesem Fall der Hinweis auf dem Schreibschutz.

Diesen Workaround kann man einfach realisieren, indem man die Anwendung über eine Verknüpfung startet und dort den Runtime-Switch in der Befehlszeile angibt. Die Befehlszeile einer Verknüpfung sieht dann etwa wie folgt aus:

"C:\Pfad\zu\MSACCESS.EXE" /runtime "C:\Pfad\zur\Anwendung.adp"

Dieser Workaround funktioniert aber nur mit maximal 20 geöffneten Instanzen der Anwendung. Wenn die Anwendung 21 mal oder mehr geöffnet wird, erscheint die Fehlermeldung 'Die ADP-Datei ist nicht im richtigen Microsoft Access Projektformat.' und es ist nicht mehr möglich weitere Instanzen zu öffnen.

Eine Bessere Lösung für das Problem ist es, jedem Benutzer eine eigene Kopie der Datei auf seinem lokalen Rechner zur Verfügung zu stellen. Zu einem bringt dieses Vorgehen leichte Performancevorteile, da die Access-Objekte nicht über das Netzwerk geladen werden müssen. Außerdem ist dieser Ansatz stabiler da jeder Benutzer nur in seiner eigenen Datei arbeitet und wenn diese beschädigt wird, keine anderen Benutzer beeinträchtig werden.

Um eine Anwendung in einem solchen Szenario regelmäßig updaten zu können, kann auf jedem Client der Start der Anwendung über ein Script oder ein Zusatzprogramm erfolgen, das ggfls. eine aktualisierte Version von einem Netzlaufwerk auf den lokalen Rechner kopiert. Diese Funktionalität kann man entweder selbst entwicklen, oder auf fertige Lösungen wie z.B. den Auto FE Updater von Tony Toews verwenden.

In einer Access-MDB-Anwendung war es mit der Funktion CurrentUser() möglich den angemeldeten Benutzer der Anwendung zu ermitteln, aber in einem Access ADP funktioniert diese Funktion nicht mehr in dieser Weise. Der Aufruf von CurrentUser liefert in einem ADP immer "Admin" zurück, egal wer gerade angemeldet ist.

Die Erklärung dafür ist einfach. In einem ADP wird die Benutzerverwaltung einzig und allein von dem SQL-Server-Backend übernommen. Es gibt in Access tatsächlich nur noch den einen Benutzer "Admin". Wenn man nun wissen möchte, welcher Benutzer am SQL-Server angemeldet ist, muss man dazu auch den SQL-Server befragen.

Die T-SQL-Funktion SUSER_SNAME() liefert den Login des Benutzers am SQL-Server. Dieser Login kann sich durchaus vom Benutzernamen in der aktuellen Datenbank unterscheiden. Dieser Funktion kann die interne ID eines Logins auf dem SQL-Server als Parameter übergeben werden, um den UserName eines anderen Benutzers zu ermittelt. Für unseren Zweck reicht es aber aus die SUSER_SNAME-Funnktion ohne Parameter aufzurufen. Also sieht das komplette SQL-Statement um den aktuellen SQL-Server Login zu erhalten wie folgt aus:

SELECT SUSER_SNAME()

Wenn man nicht den Login-Namen auf den Server, sondern den Benutzernamen in der aktuellen SQL-Server-Datenbank benötigt, kann man, analog zu dem obigen Beispiel, die Funktion USER bzw. USER_NAME() verwenden.

Um aus Access heraus diese Information zu erhalten muss man ein Recordset mit diesem SQL-Statement öffnen und den Wert dieses Feldes auslesen. Diesen Vorgang kann man komfortabel in eine eigene VBA-Funktion kapseln, die dann in dem Projekt die eingebaute Funktion CurrentUser ersetzt.

Hier nun ein Beispiel für eine solche Funktion.

Public Function AktuellerBenutzer() As String
On Error GoTo AktuellerBenutzer_Err

    Dim rs As ADODB.Recordset

    Const strSQL As String = "SELECT SUser_SName()"

    Set rs = CurrentProject.Connection.Execute(strSQL)

    AktuellerBenutzer = rs.Fields(0).Value

AktuellerBenutzer_Exit:
On Error Resume Next
    rs.Close
    Set rs = Nothing
Exit Function

AktuellerBenutzer_Err:
    MsgBox Err.Number & " " & Err.Description, vbExclamation, "Error"
    Resume AktuellerBenutzer_Exit
End Function

Die hier erwähnten SQL-Server-Funktionen enstammen dem Funktionsumfang des SQL-Servers 8.0 (SQL 2000). In den vorigen Versionen des SQL-Servers sind evtl. nicht alle genannten Funktionen vorhanden.

Wenn man eine Access-Anwendung als MDB entwickelt hat, die über eine ODBC-DSN auf eine Datenquelle (z.B. den MS-SQL-Server) zugreift, hat man bei der Verteilung der Anwendung das Problem, dass die DSN auf jedem Rechner eingerichtet werden muss, damit die Anwendung funktioniert.

Eine mögliche Lösung zu diesem Problem ist es, die benötigte DSN einfach aus der Anwendung heraus per VB(A)-Code anzulegen. Dies ist mit dem Einsatz der API-Funktion SQLConfigDataSource aus der ODBCCP32.dll relativ einfach zu realisieren.

Bevor ich den Code zum Anlegen der DSN vorstelle, vorab ein paar Begriffserläuterungen.

• DSN: Das Kürzel DSN steht für Data Source Name. Damit ist gemeint, dass sämtliche Informationen (Connection-String), die für den Zugriff auf eine Datenquelle erforderlich sind, unter einem griffigen Namen zusammengefasst werden und über diesen Namen abgerufen werden können. Die eigentlichen Verbindungsinformationen werden dabei in der Registry gespeichert (Ausnahme: File DSN).
• User DSN (Benutzer DSN): Eine solche DSN steht nur dem Benutzer, der sie angelegt hat, auf den jeweiligen Rechner zur Verfügung. Die Verbindungsdetails werden in der Registry im Schlüssel HKEY_CURRENT_USER\Software\ODBC\ODBC.INI gespeichert.
• System DSN: Diese DSN steht allen Benutzern auf den jeweiligen Rechner zur Verfügung. Die Verbindungsdetails werden in der Registry unterhalb des Schlüssels HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI gespeichert.
• File DSN (Datei DSN): Die Definition der DSN wird in einer Datei (INI-Dateiformat) gespeichert und kann von allen Benutzern, die Zugriff auf die Datei haben, genutzt werden.

Da die File DSNs einfache (INI-)Textdateien sind, die mit den integrierten VBA-Dateifunktionen oder der INI-Datei-API geschrieben werden können, werde ich hier nicht weiter auf diese DSNs eingehen. Nur der Vollständigkeit halber sei erwähnt, dass auch die ODBC-API eine Funktion (SQLWriteFileDSN) zum Schreiben der File-DSNs bereitstellt.

Das Anlegen einer System- oder User-DSN per VBA-Code ist sehr einfach, wenn man die erforderlichen API-Deklarationen in seinem Code vorgenommen hat. Dazu einfach die folgenden Zeilen in den Kopfbereich eines Standardmoduls einfügen.

Public Const ODBC_ADD_DSN = 1     ' Add user data source (User DSN)
Public Const ODBC_ADD_SYS_DSN = 4 ' Add user data source (System DSN)

Public Declare Function SQLConfigDataSource Lib "ODBCCP32.DLL" ( _
                                                    ByVal hwndParent As Long, _
                                                    ByVal fRequest As Long, _
                                                    ByVal lpszDriver As String, _
                                                    ByVal lpszAttributes As String _
                                                    ) As Long

Um die API-Funktion bequemer aufrufen zu können, sollte man sich eine kleine Wrapperfunktion schreiben, die den eigentlichen Aufruf erledigt. Dieser Wrapper könnte etwa so aussehen, um eine System-DSN anzulegen:

Public Function CreateDSN(ByVal strName As String, _
                        ByVal strDriver As String, _
                        ByVal strConnectionString As String _
                        ) As Boolean

    Dim lngRetVal       As Long
    Dim strAttribString As String
    Dim Attributes      As Variant
    Dim i               As Long
    
    strAttribString = "DSN=" & strName & vbNullChar
    Attributes = Split(strConnectionString, ";")
    
    For i = LBound(Attributes) To UBound(Attributes) Step 1
        strAttribString = strAttribString & Attributes(i) & vbNullChar
    Next i
    
    lngRetVal = SQLConfigDataSource(0, ODBC_ADD_SYS_DSN, strDriver, strAttribString)
    
    CreateDSN = CBool(lngRetVal)
    
End Function

strName ist der Name für die neue DSN, strDriver ist die genaue Bezeichnung des ODBC-Datenbanktreibers, und für das Argument strConnectionString wird ein ODBC-Connectionstring nach üblichen Schema übergeben. Die Funktion liefert True zurück, wenn die DSN erfolgreich erstellt wurde. Dass bedeutet aber nicht zwingend, dass auch alle angegebenen Informationen korrekt sind. Ein falscher Servername wird .z.B. erst deutlich, wenn man versucht sich über die DSN mit dem Server zu verbinden.

Meine Beispielfunktion legt eine System-DSN an. Ein Benutzer mit eingeschränkten Rechten ist i.d.R. nicht berechtigt eine System-DSN anzulegen. Wenn anstelle einer System-DSN eine User-DSN angelegt werden soll, muss dazu nur die Konstante ODBC_ADD_SYS_DSN beim Aufrufen der SQLConfigDataSource-Funktion durch die Konstante ODBC_ADD_DSN ersetzt werden.

Der Aufruf der Wrapper-Funktion funktioniert, am Beispiel der Pubs-Datenbank auf einem Microsoft-SQL-Server dann in etwa so:

If CreateDSN("meineDSN","SQL Server", "Server=meinServer;Database=pubs") Then
  MsgbBox "DSN erfolgreich erstellt"
Else
  MsgbBox "Fehler! DSN nicht erstellt"
End If

Die vollständige Dokumentation der SQLConfigDataSource-Funktion findet man unter folgender Adresse in der MSDN Library.

Evtl. aufgetretene Fehler kann man mit der ODBC-API-Funktion SQLInstallerError ermitteln, die ich aber im Rahmen dieses Artikles nicht ausführlicher vorstellen werde.

Du hast in einem Access-ADP das Problem, dass du eine große Menge an Datensätzen anzeigen oder verarbeiten (UPDATE/INSERT/DELETE) willst, aber dass immer nur maximal 10.000 Datensätze angezeigt bzw. verarbeitet werden.

Der einfache Grund hierfür ist, dass Access per Standardeinstellung die Anzahl der bearbeiteten Datensätze auf 10.000 begrenzt.

Das Problem lässt sich mit zwei verschiedenen Ansätzen lösen. Die einfache Lösung ist, die Standardeinstellung von Access den eigenen Bedürfnissen anzupassen. Dazu kann man über das Menü Extras-Optionen-Weitere-Client/Server-Einstellungen-Vorgabe der max. Datensätze einfach einen anderen geeigneten Wert einstellen. Diese Vorgabe gilt jeweils nur für die aktuelle Datenbank.

Diese Änderung der Standardeinstellung lässt sich auch über VBA-Code vornehmen, indem man über die SetOption-Methode die Row Limit-Option verändert. Der folgende Beispielcode demonstriert dies (das Row Limit wird auf 500 Datensätze reduziert):

Call Application.SetOption("Row Limit",500)

Bevor man das Thema damit komplett abhakt, sollte man aber bedenken, dass das Access-Team von Mircosoft diese Voreinstellung nicht einfach nur vorgenommen hat, um uns arme Entwickler zu ärgern, sondern dass diese Voreinstellung durchaus ihre Berechtigung hat. Überleg mal; wer will ersthaft eine Liste mit mehr alös 10.000 Datensätzen am Bildschirm durchgehen, oder sich gar duch soviele Datensätze in einer Einzelansicht klicken? - Normalerweise niemand! Weiterhin sollte man bedenken, dass mit einer globalen Änderung dieser Option der SQL-Server dazu gezwungen wird eine Menge Datensätze zum Access-Client zu schaufeln, für die sich dort niemand interessiert. Das belastet den Server und das Netzwerk völlig unnötig.

Anstatt das Row Limit für alle Abfragen in den Access-Standardeinstellungen zu verändern kann man auch in alle Stored Procedures auf dem SQL-Server, die Änderungen an dem Datenbestand vornehmen den Rowcount (Synonym für die Row Limit-Option in Access) per T-SQL setzen. Die entsprechende T-SQL-Anweisung lautet einfach:

SET ROWCOUNT 0

Der Wert 0 für den Rowcount deaktiviert die Beschränkung der betroffenen Datensätze vollständig. D.h. es werden immer alle Datensätze verarbeitet, die den jeweiligen Kriterien entsprechen. Wenn man den Rowcount innerhalb einer Stored Procedure setzt, gilt der jeweilige Wert nur innerhalb der Stored Procedure, nicht für die gesamte Verbindung.

Natürlich kann man auch vor AdHoc-SQL-Statements, die man über die Connection des ADPs ausführt, den Rowcount, wie oben beschrieben, per T-SQL auf einen geeigneten Wert setzen. Allerdings möchte ich dieses Vorgehen nicht empfehlen, da man das dann vor jedem einzelnen SQL-Statement berücksichtigen muss und das meiner Meinung nach zu fehlerträchtig ist. Wenn man also von Ad-Hoc-SQL gebrauch macht um Daten zu ändern, sollte man besser dafür sorgen, dass das Row Limit für die ganze Verbindung des ADPs immer korrekt eingestellt ist. Die bessere Alternative ist natürlich grundsätzlich sämtliche DML-Aktionen ausschließlich über Stored Procedures auszuführen.

Ich würde in jedem Fall für alle Stored Procedures, die Daten verändern immer explizit den ROWCOUNT innerhalb der Stored Procedure auf 0 setzen, wie oben beschrieben. Damit ist sichergestellt, dass die Stored Procedure als autarke Einheit immer funktioniert und nur von eventuellen Eingabeparametern, aber nicht von gobalen Einstellungen, wie dem Rowcount der Connection, abhängig ist.

Ich habe im Moment nicht die Zeit (und die Lust) hier auf spezielle Probleme mit Microsoft Access im Zusammenspiel mit dem Oracle Datenbankserver einzugehen, Daher möchte ich hier nur auf zwei Quellen hinweisen, die gängige Probleme mit Access und Oracle behandeln.

• Ich selbst habe vor einiger Zeit einen Artikel für den Access Report geschrieben, der die wesentlichen Probleme (und deren Lösung), denen man im Zusammenhang Access & Oracle begegnet, erläutert.
  -> http://www.codekabinett.com/rdumps.php?targetDoc=RendOra
• Christoph Jüngling hat auf seiner Website einige Informationen zum Einsatz von Microsoft Access als Frontend für Oracle zusammengestellt.
  -> http://www.juengling-edv.de/ao/

Wie kann man die Verbindungsdaten für ein Access Data Project erst zur Laufzeit festlegen?

Wenn man weiß, wie es funktioniert ist das recht einfach, aber die entsprechenden Objekte/Methoden sind in der Objekthierarchie nicht ganz intuitiv zu finden, daher will ich hier kurz das Vorgehen erläutern.

Eigentlich sollte man annehmen, dass man zu diesem Zweck einfach die Connection.Open-Methode der Currentproject.Connection (ADODB.Connection) verwenden kann. Dies trifft aber nur indirekt zu. Es funktioniert nicht, das Connection-Objekt direkt zu verwenden, stattdessen muss man die OpenConnection- bzw. CloseConnection-Methode des CurrentProject-Objektes verweden.

Den richtigen ConnectionString für die Verbindung zu ermitteln kann evtl. ein weiteres Problem darstellen. Denn Wenn man sich den Connectionstring der CurrentProject.Connection anschaut, wird dort als Provider "Microsoft.Access.OLEDB.10.0" verwendet. Wenn man aber versucht mit diesem Provider eine Verbindung zu öffnen, schlägt dies immer fehl. Stattdessen muss man auch für Access einen typischen OleDB-ConnectionString zum SQL-Server verwenden und dabei den Provider "SQLOLEDB.1" angeben, so wie man ihn aus der BaseConnection-Property des CurrentProject-Objektes auslesen kann. - Bevor ihr es versucht; es funktioniert nicht, dort einen Provider für ein anderes DBMS anzugeben. (Siehe dazu auch den Artikel Anderes Backend-DBMS fuer Access Data Projects).

Mit den obigen Informationen ausgestattet, ist es eine Kleinigkeit eine VBA-Prozedur zu schreiben, die dem ADP eine neue Verbindung zuweist.

Public Sub OpenADPConnection(ByVal strUser As String, ByVal strPassword As String)

    Const strCONNECTION_STRING As String = _
          "Provider=SQLOLEDB;Data Source=deinServer;Initial Catalog=deineDatenbank;"

    CurrentProject.OpenConnection strCONNECTION_STRING, strUser, strPassword

    If Not CurrentProject.IsConnected Then
        MsgBox "Es konnte keine Verbindung hergestellt werden!"
    End If
    
End Sub

Zuletzt noch ein Hinweis zu einem eng verwandten Problem. Meist möchte man ja die Verbindung eines ADPs zur Laufzeit setzen, um eine fertige Anwendung in der Umgebung des Kunden zu deployen. Dabei tritt der unangenehme Effekt auf, dass Access beim Öffnen eines ADPs erst mal versucht, die Verbindung zu dem Server und der Datenbank herzustellen, die zuletzt verwendet wurden. Da der Entwicklungsserver i.d.R. bei dem Wechsel von einer Entwicklungsumgebung zu dem Live-System aber nicht mehr direkt zur Verfügung steht, bleibt die Access-Anwendung dann beim Start so lange hängen, bis der Connection-Timeout abgelaufen ist und anschließend wird eine Fehlermeldung ausgegeben, dass der Server nicht erreichbar ist.

Um diesen unangenehmen Effekt zu verhindern sollte man seine ADP-Anwendung ohne Verbindungsdaten ausliefern und dann, wie oben beschrieben, die Verbindung per VBA beim Start der Anwendung aufbauen. Die gespeicherten Verbindungsinformationen kann man aus der Anwendung entfernen, indem man per VBA die OpenConnection-Methode ohne Parameter aufruft.

Call CurrentProject.OpenConnection

Danach ist das ADP beim Start verbindungslos und es wird nicht mehr automatisch versucht eine Verbindung aufzubauen.

Das Problem

Du hast eine Microsoft Access Anwendung auf einer 64-Bit-Version von Windows 7 und möchtest diese zu einer ODBC-Datenquelle (z.B. einer SQL-Server-Datenbank) verbinden. Du hast die DSN (Data Source Name) dafür mit dem ODBC-Datenquellen-Administrator konfiguriert und Dich mit dem „Test“-Feature des ODBC-Admin davon überzeugt, dass sie auch funktioniert. Wenn Du in deiner Access Anwendung eine verknüpfte Tabelle mit dieser Verbindung hinzufügen möchtest, ist diese aber bei der Auswahl der Datenquellen nicht sichtbar. Wenn Du in der Anwendung bereits eine bestehende Tabelle hast, die diese Verbindung nutzt, lässt sich diese nicht öffnen. Alle Verbindungsversuche scheitern mit einem SQLState 08001 Fehler.

Die Erklärung

Access ist üblicherweise als 32-Bit-Anwendung installiert. Auf einem 64-Bit-Betriebssystem läuft Access dann in dem 32-Bit-WOW(Windows-on-Windows)-Subsystem. Alle Verknüpfungen (z.B. in der Systemsteuerung) auf den ODBC-Datenquellen-Administrator auf Windows 7 x64 öffnen aber die 64-Bit-Version dieses Tools. Was auch immer Du dort siehst oder konfigurierst, ist für deine Access Anwendung komplett irrelevant, denn diese kann die dort konfigurierten Einstellungen nicht aus der Registry lesen, denn das 32-Bit Subsystem verwendet einen komplett eigenen Unterbereich.

Die Lösung

Die Lösung ist einfach, wenn man diese Zusammenhänge kennt. Du musst explizit die 32-Bit-Version des ODBC-Datenquellen-Administrators öffnen und deine DSN dort konfigurieren. Um absolut sicher zu gehen, dass Du die richtige Version des Tools verwendest, solltest Du den Windows Explorer verwenden, um die Datei C:\WINDOWS\syswow64\odbcad32.exe direkt zu öffnen. (Der Ordner „SysWow64“ ist das Systemverzeichnis des 32-Bit-Subsystems. – Ja, das ist etwas irritierend.)

Kein Problem auf Windows 8

Dieses Problem wurde mit Windows 8 gelöst. Dort zeigt der ODBC-Datenquellen-Administrator in der Titelleiste klar an, ob es sich um die 32- oder 64-Bit-Version handelt. Wenn sowohl die 32- als auch 64-Bit-Version des verwendeten Treibers für das Datenbanksystem vorhanden ist, wird auf Windows 8 außerdem die DSN automatisch sowohl in der nativen 64-Bit-Umgebung als auch im 32-Bit-Subsystem erstellt.

Nachtrag zu OleDb-UDL-Dateien

Ein ähnliches Problem besteht auch wenn man die Datenverknüpfungseigenschaften von UDL-Dateien auf Windows x64 aus dem Explorer mit der OpenDSLFile-Funktion der oledb32.dll öffnet. (Das passiert standardmäßig bei einem Doppelklick auf eine UDL-Datei.) Es werden dann nur die 64-Bit-OleDb-Provider angezeigt, weil die 64-bit-Version der oledb32.dll verwendet wird.

Um die Liste der verfügbaren die 32-Bit-OleDb-Provider anzuzeigen, muss man die Datenverknüpfungseigenschaften mit der 32-bit-Version der oledb32.dll öffnen. Du kannst die folgende Befehlszeile (als Administrator ausführen) verwenden um einen Open32-Eintrag im Kontext-Menü des Windows Explorers für UDL-Dateien zu erstellen.

Danke an Markus Melk, der mich auf dieses Problem hingewiesen hat und ein .reg-Script für die Erstellung des Open32 Kontext-Menü-Eintrags bereitgestellt hat.

SQL-Server-Express ist der natürliche Upgrade-Pfad von einer reinen Access-DB zu einer echten Client-Server-Anwendung. Doch auch dort ist eine regelmäßige Datensicherung unerlässlich. Eine klassische Dateisicherung ist jedoch mit einer Client-Server-Datenbank nicht mehr ohne Weiteres möglich, daher erläutere ich die Grundlagen der Datensicherung mit Microsoft-SQL-Server, mit Schwerpunkt auf den Anforderungen für eine SQL-Express-Datenbank.

SQL-Server-Express ist eine gute Wahl für Datenbanken in kleinen Unternehmen oder Abteilungen. Die einzige Komponente, die fehlt, ist der SQL Agent, um automatische Datensicherungen zu planen.

Hier ist eine vollständige Anleitung, wie man dennoch automatische, zeitgesteurte Backups erzeugen kann. Dafür werden nur Tools verwendet, die entweder bei SQL Express oder dem Windows Betriebssystem mitgeliefert werden.

Dieser dritte und letzte Artikel zur Sicherung und Wiederherstellung von Microsoft SQL Server Express Datenbanken schließt das Thema ab. Ich erkläre hier, wie du eine SQL Express Datenbank aus einem Backup wiederherstellst. Dabei werden die zwei gängigsten Szenarien behandelt, die eine Wiederherstellung erfordern.

Verknüpfte ODBC Tabellen sind der empfohlene Weg um eine Client-Server-Anwendung mit Microsoft Access und einem Backend-DBMS wie SQL Server, Oracle oder MySQL zu erstellen. – I habe dazu diesen uralten, aber immer noch relevanten, Text wieder ausgegraben, der versteckte Mechanismen von verknüpften ODBC-Tabellen und ihre Auswirkungen auf die Performance erklärt.