Ein Kunde hat aus der Microsoft Office Small Business Version den Business Contact Manager im Einsatz. Dabei ist auf einem zentralen PC eine SQL Express Datenbank installiert, welche die Informationen hält und aus deren Tabellen die Outlook Ansichten des Business Contact Manager gebildet werden. Die Daten sind also nicht in Outlook gespeichert und werden auch nicht mit Outlook Methoden repliziert, sondern sie werden nur mit Outlook angezeigt.

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!

Ruft man die Installation des Microsoft SQL Server Express 2008 direkt von der Website auf

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:

Twitter Comments

	cpohle SQL Server Express 2008 installiert standardmäßig eine Named Instance http://pohle.de/5qq #wp #li #xng #fb
	Re-Tweet | Reply | View Tweet

Heute mußte ich feststellen, daß der Befehl “DoCmd.Save” in Microsoft Access 2003 nicht, wie erwartet, funktioniert. Ich habe ihn in einem Formular in Verwendung, dort wird, wenn der Anwender das Jahr auswählt, aus dem Jahr und einer fortlaufenden Nummer die sogenannte “Seriennummer” des Dokumentes generiert, in das Feld Seriennummer im Formular eingesetzt und dann das Formular gesichert, damit der nächste Benutzer, der ein neues Dokument anlegt, eine neue Seriennummer generiert:

‘ 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.

Ich betreue ja einige Microsoft Access und Microsoft VB Anwendungen bei meinen Kunden, die ihre Daten im Microsoft SQL Server speichern. Dort habe ich natürlich nach Rückfrage immer die Möglichkeit in den Serverraum zu gelangen und die SQL Konsole aufzurufen – schlecht nur, wenn man per Remote Control auf einer Station eines Benutzers aufgeschaltet ist und schnell ein Attribut einer Spalte oder Tabelle im SQL Server ändern muß.

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.

Ich habe neulich ein Plugin für eine Anwendung von mir programmiert, eine Literaturdatenbank (Access Frontend, SQL Backend), die ich 1999 für einen Kunden erstellt habe und seither immer wieder mal pflegen und vor allem die neuen Ideen der Betreiberin einbauen darf. Dafür habe ich ein Import Plugin für einzelne Bücher aus Lehmanns Online Buchhandlung geschrieben.

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.

Wenn man eine SQL Datenbank bereinigt und dabei viele Daten aus den Tabellen löscht, dann wird das Log der betreffenden Datenbank recht groß und jeglicher Versuch, die Datenbank, samt Log zu shrinken, schlägt insofern fehl, daß die Datendateien nicht wirklich kleiner werden.

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.

Die GUI vom Microsoft SQL Server erlaubt das Zurückspeichern einer Datenbank von einem Backup, jedoch nicht unter einem neuen Namen. Da kann man zwar einen anderen Namen für die Datenbank eingeben in das Restore Fenster, aber es wird immer die Fehlermeldung ausgegeben, daß der Datenbank Name der zurückzuspeichernden Datenbank falsch ist.

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