Unter Linux würde ich das Paket installieren, es würde mich warnen, daß noch Abhängigkeiten aufzulösen sind, ich würde Yes antworten und Linux würde einfach die benötigten Komponenten herunterladen und installieren, bevor das eigentliche Setup losgeht.

Nicht so Windows. Ruft man das SQL Server 2008 Express Setup auf, dann wird man erstmal ermahnt, daß das aktuelle .NET Framework fehlt auf dem Server (das hat halt bisher noch keiner gebraucht):

Aber anstelle das einfach herunterzuladen und zu installieren (der Server hätte Internetzugang), muß man, wenn man das .NET Framework nicht irgendwo im Netz rumliegen hat, die Zeile aus der MSG Box abtippen (einfach anklicken geht nicht) und in einen Browser eingeben, das .NET Framework dann herunterladen und installieren (das übrigens lädt die benötigten Komponenten selbst nach, bis zu 235 MB sind das):

Jetzt können wir SQL Setup starten? Weit gefehlt, denn jetzt ist der Windows Installer dran, der aktualisiert werden muß:

Nun? Ja, nun geht es und bei der Installation der “Setup Support Files” kommen mir dann schon die Tränen, denn man hätte die mühsam mit der Hand heruntergeladenen und mit zweifachem Server Reboot installierten Komponenten ja auch einfach hier mit einbauen können, oder?

Wiederspricht noch jemand, wenn ich behaupte, Linux ist hier Administratorenfreundlicher?

Ach ja, ein Goodie hab’ ich noch, aber das wußte ich ja vorher: In den 102 MB für den SQL Server Express ist die Managementkonsole nicht drin, die muß man extra herunterladen, nochmal 172 MB groß.

Möchten mehrere Benutzer mit diesen Informationen arbeiten, dann kann man diese freigeben. Bei diesem Vorgang wird eigentlich nichts anderes getan, als am SQL Express Server ein Netzwerkprotokoll gebunden und den Benutzern ein Zugriffsrecht auf diesen SQL Server gegeben.

Diese Freigabe kann nun mit einer sehr nichtssagenden Fehlermeldung

Fehler beim Übernehmen von Änderungen. Ihre Änderungen wurden nicht erfolgreich übernommen.

fehlschlagen und Outlook stürzt danach ab:

Versteht sich von selbst, daß dazu nichts wirklich hilfreiches in den einschlägigen Supportdatenbanken zu finden ist. Ich beschreibe, was mir in diesem speziellen Fall letztendlich (nach einigen erfolglosen Versuchen) geholfen hat:

• Ich habe vorsichtshalber die Datenbank gesichert (aus Unternehmensools .- Datenbank verwalten, Knopf “Datenbank sichern”).
• Dann habe ich aus der Systemsteuerung das “Microsoft Office Outlook 2003 mit Business Contact Manager Update” deinstalliert.
• Als nächstes die “Microsoft SQL Server Desktop Engine (MICROSOFTSMLBIZ)” deinstalliert.
• Den Patch “KB954459″ deinstalliert, das ist MSXML 6.0 SP2 (ich mußte dafür den Office Cleanup Wizard zu Hilfe nehmen)
• Und als letztes die “Unterstützungsdateien für das Microsoft SQL Server Setup”
• Sollte danach noch irgendetwas in der Liste der Programme sein, das auf Business Contact Manager hindeutet, würde ich das auch deinstallieren.
• Rechner rebooted
• Setup von Microsoft XML 6.0, keine XML Service Packs!
• Erneuter Reboot des Rechners
• Dann den Business Contact Manager für Outlook 2003 geladen und installiert. Dabei wurde die SQL Engine wieder installiert.
• Reboot des Rechners
• Start von Outlook und Konfiguration des Business Contact Managers. Dabei auf “Datenbank auswählen” geklickt und die bereits vorher verwendete Datenbank wurde automatisch eingetragen:

• Es waren nun alle Informationen aus dem Business Contact Manager wieder im Outlook verfügbar – ein Restore der Datenbank aus der Sicherung war nicht notwendig!
• Download und Setup des Service Pack 2 für Business Contact Manager (das ist im englischen übrigens Service Pack 3!)
• Klar: Reboot.
• Download und Setup des Service Pack 3 für Business Contact Manager (das ist im englischen übrigens Service Pack 4). Dabei wurde auch ein Update der SQL Express Version durchgeführt und ein Hinweis angezeigt, daß die Datenbanken erneut freigegeben werden müssen.
• Letzter Reboot

Nun ließ sich die Datenbank wieder einwandfrei für die Benutzer freigeben!

Dann öffnet sich ein komfortabler Installer, der alle notwendigen Schritte automatisch erledigt. Startet man direkt im Anschluß dann das SQL Server Management Studio und drückt auf “Connect”, dann erhält man eine Fehlermeldung, daß die Verbindung zum SQL Server nicht aufgebaut werden kann:

Die Lösung? Der so komfortable Installer installiert, ohne das irgendwo explizit zu nennen, keine Default Instance des SQL Server, sondern eine Named Instance. Die hat zwar immer den Namen “SQLEXPRESS”, aber das muß eben beim Verbindungsaufbau angegeben werden:

‘ Generate next Serial Number
Dim strNextSerialNumber
strNextSerialNumber = _
   Mid(sqlDocuments!maxSerialNumber, 6)
strNextSerialNumber = strNextSerialNumber + 1
If IsNull(strNextSerialNumber) Then
‘ Enter first Number
strNextSerialNumber = “000001″
Else
‘ Enter generated Number
strNextSerialNumber = Left(“000000″, 6 – _
   Len(strNextSerialNumber)) & strNextSerialNumber
End If
Me.docSerialNumber = _
   Me.docYear & “_” & strNextSerialNumber

‘ Save Immediately
DoCmd.Save

So war es gedacht, doch kam es immer wieder vor, daß zwei Dokumente die gleiche Seriennummer bekommen sollten, was natürlich durch den Constraint in der Datenbank verhindert wird.

Nach einigem Rumprobieren, kam ich auf den Befehl

DoCmd.RunCommand acCmdSaveRecord

der genau das tut, was “DoCmd.Save” eigentlich tun sollte, nämlich die Daten aus dem Formular sofort in die Datenbank zurückschreiben.

Dazu benutze ich gerne das QueryExpress von Joseph Albahari, das ist nur eine EXE Datei, es muß auch nichts installiert werden. Ruft man es auf, gibt man den Servernamen, Benutzernamen und Kennwort ein

und man ist mit dem Server verbunden und kann alle SQL Kommandos absetzen, für welche der verwendete Benutzer berechtigt ist. QueryExpress gehört bei mir zur Grundausstattung bei jedem Kunden, der eine Datenbankanwendung von mir einsetzt.

Wichtiger Tipp: QueryExpress läuft nicht von Netzwerklaufwerken – bevor man es aufruft, muß man es auf eine lokale Festplatte kopieren.

Dabei lief mir tatsächlich, weil ich irgendwann einfach meinen Nachnamen als Suchbegriff eingegeben hatte, mein altes Buch von 1991 wieder über den Weg und ich erinnerte mich daran, daß ich ja tatsächlich schon mal ein Buch geschrieben hatte. Heute nicht mehr erhältlich und auch nur noch als Sammleredition nützlich, denn was da drin steht, ist inzwischen (leider) total überholt.

Hier muß man zunächst die Logeinträge wegwerfen, das geht im Query Analyzer mit dem Befehl

BACKUP LOG dbname WITH TRUNCATE_ONLY;

(statt “dbname” den Namen der SQL Datenbank einsetzen). Danach den Shrink aufrufen (aus dem SQL Server Manager) und die Datenbank wird, wie gewünscht, verkleinert.

Mit Transact SQL hingegen funktioniert das. Dazu muß man zunächst unter “Server Objects” – “Backup Devices” ein Backup Device anlegen, das auf die Datei des zurückzuspeichernden Backups zeigt:

Dann kann man in Transact SQL ein Statement zusammenstellen, das die Datenbank aus diesem File in eine Neue Datenbank zurückspeichert. Das geht mit folgenden Schritten:

• Den Namen der zurückzuspeichernden Datei gibt man im RESTORE DATABASE Statement an
• Der Name des soeben angelegten Backup Devices steht im FROM Statement
• Die neu anzulegenden Datenbankdateien gibt man mit den MOVE Statements für Daten- und Logfiles an

sieht dann so aus:

USE master
GO

 

RESTORE DATABASE INVENTORY_TESTENV
FROM Inventory_Restore
WITH RECOVERY,
MOVE ‘INVENTORY_Data’ TO ‘F:\DATA\MSSQL\Data\INVENTORY_TESTENV_Data.MDF’,
MOVE ‘INVENTORY_Log’ TO ‘E:\LOGS\MSSQL\Data\INVENTORY_TESTENV_Log.ldf’
GO