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