6. Auflage (2019)

5. Auflage (2016)

4. Auflage (2013)

3. Auflage (2011)

2. Auflage (2009)

1. Auflage (2008)

S. 101 Mitte

Dort muss es richtig heißen:

Das allein reicht aber noch nicht aus, denn die Umsetzung dieses Datenmodells in Tabellen würde es zulassen, dass ein und derselbe Wert des Primärschlüssels pero_id mehrfach in der Spalte pero_id_f auftaucht, dass also eine PersonOeffentlich auch zu mehreren PersonGeheim gehören kann - was ja aber nicht sein soll.“

S. 212 Mitte

Der VBA-Code muss richtig lauten:

If CDbl(txtErsteZahl) < CDbl(txtZweiteZahl) Then
   MsgBox ("Die erste Zahl ist kleiner!")
Else
   MsgBox ("Die zweite Zahl ist kleiner oder gleich der ersten!")
End If

S. 217 Oben

Der VBA-Code muss richtig lauten:

lngErsteZahl = CLng(txtErsteZahl)
lngLetzteZahl = CLng(txtLetzteZahl)
lngSchrittweite = CLng(txtSchrittweite)

For lngLaufzahl = lngErsteZahl To lngLetzteZahl Step lngSchrittweite
   MsgBox "Jetzt bin ich bei " & Str(lngLaufzahl) & "!"
Next lngLaufzahl

S. 218 Oben

Der VBA-Code muss richtig lauten:

lngLaufvariable = 1

Do While lngLaufvariable < CLng(txtEntscheidungswert)
   MsgBox "Jetzt bin ich bei " & Str(lngLaufvariable) & "!"
   lngLaufvariable = lngLaufvariable + 1
Loop

S. 281 unten

(Danke an Herrn Keller für den Hinweis!)
Im Listing 7.8 muss es richtig heißen: "ORDER BY tblRaum.raum_id;"

S. 283 unten

(Danke an Herrn Keller für den Hinweis!)
Die Abfrage qryPlanRaumDozVer_LeftOuterJoin muss richtig heißen qryPlanRaumDozVer_RightOuterJoin. Entsprechend muss in der Abbildungsunterschrift 7.15 auch RIGHT OUTER JOIN statt LEFT OUTER JOIN stehen.

S. 212 Mitte

Der VBA-Code muss richtig lauten:

If CDbl(txtErsteZahl) < CDbl(txtZweiteZahl) Then
   MsgBox ("Die erste Zahl ist kleiner!")
Else
   MsgBox ("Die zweite Zahl ist kleiner oder gleich der ersten!")
End If

S. 217 Oben

Der VBA-Code muss richtig lauten:

lngErsteZahl = CLng(txtErsteZahl)
lngLetzteZahl = CLng(txtLetzteZahl)
lngSchrittweite = CLng(txtSchrittweite)

For lngLaufzahl = lngErsteZahl To lngLetzteZahl Step lngSchrittweite
   MsgBox "Jetzt bin ich bei " & Str(lngLaufzahl) & "!"
Next lngLaufzahl

S. 218 Oben

Der VBA-Code muss richtig lauten:

lngLaufvariable = 1

Do While lngLaufvariable < CLng(txtEntscheidungswert)
   MsgBox "Jetzt bin ich bei " & Str(lngLaufvariable) & "!"
   lngLaufvariable = lngLaufvariable + 1
Loop

S. 187 oben

Statt "Die Formel WERT(LINKS(B3;FINDEN("€";B2)-1)) ..." muss es heißen "Die Formel WERT(LINKS(B2;FINDEN("€";B2)-1)) ... "

S. 311

Da es zu dem Thema "Eingebettetes Makro vs. Ereignisprozedur" immer mal wieder Fragen gibt, habe ich dazu eine etwas umfangreichere Ergänzung geschrieben:

Bei den Makros muss man zwischen "Eingebetteten Makros" und selbst geschriebenen Makros unterscheiden. "Eingebettete Makros" legt Access automatisch an, wenn Sie den Steuerelement-Assistenten benutzen, um z.B. einen Button auf einem Formular zu generieren, der den Befehl "Gehe zum nächsten Datensatz" ausführt. Wenn Sie den Button erstellt haben, dann in der Entwurfsansicht mit der rechten Maustaste darauf klicken und "Eigenschaften / Ereignis" wählen, sehen Sie unter "Beim Klicken" den Eintrag "[Eingebettetes Makro]". Selbst erstellte Makros in VBA zu konvertieren, ist kein Problem: Sie öffnen das Makro in der Entwurfsansicht und wählen im Register "Entwurf" den Befehl "Makros zu Visual Basic konvertieren". "Eingebettete Makros" können Sie (zumindest in Access 2010) NICHT zu VBA konvertieren. Das wird von Microsoft selber als Bug eingeschätzt (error-when-trying-to-convert-form-macro-to-visual) Auf dieser Webseite wird allerdings auch ein Workaround empfohlen: Einfach selber ein neues Makro anlegen, den Code des "Eingebetteten Makros" dorthin kopieren und dann das selbst erstellte Makro konvertieren. Anschließend wählen Sie in der Entwurfsansicht des Steuerelements wieder "Eigenschaften / Ereignis" und schalten dann "Beim Klicken" auf "Ereignisprozedur" um. Dorthinein können Sie dann den konvertieren VBA-Code kopieren. Das klingt ganz simpel - dabei sind aber einige Tricks zu beachten:

Anlegen des eigenen Makros:

• "Erstellen / Makro"
• "Neue Aktion hinzufügen": "Kommentar" (Wenn das selbst erstellte Makro völlig leer ist, können Sie später auch nichts hinzufügen. Darum dieser dummy-Eintrag!)
• Makro speichern

• Entwurfsansicht des Formulars
• Rechtsklick auf ein Steuerelement (z.B. ein Button)
• "Eigenschaften / Ereignis"
• beim Ereignis (z.B. "Beim Klicken") Klick auf den kleinen Button mit den drei Punkten
• Makro-Editor öffnet sich
• Links-Klick auf den ersten Makrobefehl
• Umschalt-Taste ("Shift") gedrückt halten und Links-Klick auf den letzten Makrobefehl
• alle Makrobefehle werden markiert
• Achtung - ganz wichtig: Jetzt müssen Sie mit der RECHTEN Maustaste auf die RICHTIGE Stelle klicken! Und zwar müssen Sie zunächst (OHNE ZU KLICKEN!) mit der Maus über einen der fett gedruckten Makrobefehle fahren, so dass der Mauszeiger sich zu einer Hand mit ausgestrecktem Zeigefinger verwandelt. DANN können Sie rechts klicken und aus dem Kontextmenü den Befehl "Kopieren" wählen. Wenn Sie nämlich an der falschen Stelle rechts klicken, wird die Auswahl aller Makrobefehle wieder aufgehoben!

• öffnen des selbst geschriebenen Makros in der Entwurfsansicht
• Rechtsklick auf den Satz "Klicken Sie hier, wenn Sie einen Kommentar eingeben möchten." (Achtung: NICHT auf "Neue Aktion ausführen"!!)
• aus dem Kontextmenü "Einfügen" auswählen
• der kopierte Makrocode erscheint
• aus dem Menü "Entwurf" den Befehl "Makros zu Visual Basic konvertieren" auswählen
• VBA öffnet sich
• dort steht unter "Module" ein neuer Eintrag "Konvertiertes Makro - ..."

• den VBA-Code des Makros markieren und kopieren (Achtung: OHNE die erste Zeile "Function ..." und OHNE die letze Zeile "End Function")
• wechseln zu Access und öffnen des Formulars in der Entwurfsansicht
• Rechtsklick auf das Steuerelement und "Eigenschaften / Ereignis"
• beim richtigen Ereignis (z.B. "Beim Klicken") durch Öffnen der Klappbox umschalten auf "Ereignisprozedur"
• Klick auf den Button mit den drei kleinen Punkten
• VBA-Editor öffnet sich
• die Einfügemarke steht zwischen "Private Sub ..." und "End Sub"
• dort Rechtsklick + "Einfügen"
• der konvertierte VBA-Code erscheint
• Achtung - jetzt ist noch eine kleine, aber wichtige Änderung erforderlich: Das Makro wurde nämlich in eine "Function" konvertiert, die Ereignisprozedur ist aber eine "Sub". Also müssen Sie innerhalb des gerade eingefügten Codes überall das Wort "Function" durch "Sub" ersetzen!

ab S. 74

Die Bezeichnungen der Datentypen in den logischen Datenmodellen haben folgende Bedeutung:

S. 170

Statt "Klicken Sie auf 'Optionen' und wählen Sie im Kombinationsfeld 'Suchen' den Eintrag 'Arbeitsmappe' aus." muss es heißen "Klicken Sie auf 'Optionen' und wählen Sie im Register 'Suchen' bei 'Durchsuchen' den Eintrag 'Arbeitsmappe' aus."

Statt "Geben Sie bei 'Suchen nach' und bei 'Ersetzen durch' jeweils ein Gleichheitszeichen ein." muss es heißen "Geben Sie im Register 'Ersetzen' bei 'Suchen nach' und bei 'Ersetzen durch' jeweils ein Gleichheitszeichen ein."

Nachtrag am Ende des Absatzes direkt über "AUFSTATUS": Sollten die Fehlermeldungen #NAME? immer noch nicht verschwunden sein, so liegt das daran, dass ich die Excel-Funktion ZUFALLSBEREICH() benutze, die nicht bei jeder Excel-Installation sofort verfügbar ist. Sie muss dann als Add-In nachträglich geladen werden. Dazu müssen Sie in den verschiedenen Excel-Versionen folgendermaßen vorgehen:

• Excel 2003: Extras / Add-Ins; Häkchen bei "Analyse-Funktionen" (engl. "Analysis Toolpak") setzen und Ok
• Excel 2007: Office-Button / Excel-Optionen / Gehe zu / Häkchen bei "Analyse-Funktionen" (engl. "Analysis Toolpak") setzen und Ok
• Excel 2010: Datei / Optionen / Add Ins / Gehe zu / Häkchen bei "Analyse-Funktionen" (engl. "Analysis Toolpak") setzen und Ok

Außerdem ...
... hat ein aufmerksamer Leser (Danke an Herrn Dittmann!) noch folgendes herausgefunden: In der Excel-Datei mit den Testdaten für die Firmen-DB ("Firma-Testdaten-v301.xls") tritt ein ganz merkwürdiger Fehler auf. An einigen Stellen steht statt der deutschen Funktion "ZUFALLSBEREICH" die englische Funktion "RANDBETWEEN"; warum auch immer - ich kann's mir nicht erklären, wie das passiert ist. Das hat zwar normalerweise keinen Einfluss auf die Funktionsweise - trotzdem gibt es hier eine neue Version dieser Datei zum Download: Firma-Testdaten-v302.xls.

Achtung!

Die folgenden Fehlerkorrekturen gelten für Ihr Buch NICHT, wenn auf Seite 4 links unten steht "2., korrigierter Nachdruck 2012". Dort sind diese Fehler bereits behoben!

Buch-CD

Die auf der CD befindlichen Dateien zur Installation der Access Runtime und der Access Developer Extensions funktionieren nicht. Offenbar haben aber viele Leser meinen Rat auf S. 376 befolgt und sich lieber die aktuellste Version direkt bei Microsoft heruntergeladen. Anders kann ich es mir nicht erklären, dass sich erst ziemlich spät der erste Leser deswegen bei mir gemeldet hat.
Darum hier noch einmal der Rat an alle Leser: Die Installationsdateien von der CD lieber gar nicht erst benutzen, sondern nach "download access 2007 runtime" oder "download access 2010 runtime" googeln und dann die aktuellste Version von dort herunterladen und benutzen!

S. 21

Der Verweis auf die "Microsoft Forms 2.0 Object Library" macht offenbar Probleme. Einerseits findet man in verschiedenen Quellen im Internet Hinweise darauf, dass diese Library Abstürze verursachen kann. Andererseits finden etliche Leser diesen Verweis überhaupt nicht in der Liste der möglichen Verweise, so dass sie ihn auch nicht aktivieren können. Meine Tests haben - bisher jedenfalls - ergeben, dass meine Beispielanwendungen auch ohne diesen Verweis funktionieren. Bitte probieren Sie es einfach - sollte es daraufhin Fehlermeldungen geben, so teilen Sie es mir bitte mit und ich werde mich darum kümmern.

Noch ein Hinweis zu diesem Thema für Leute, die diese Library trotzdem benutzen wollen oder müssen - sie aber in der Liste der möglichen Verweise nicht finden: Die Datei, in der sich diese Library befindet, heißt "FM20.DLL" und befindet sich im Ordner WINDOWS/system32!

S. 40 unten und S. 41 oben

Statt "frmDatentypen" muss es heißen: "frmTypen"!

S. 68

In der ersten Zeile des zweiten Absatzes muss es statt "... auf der Registerkarte Daten ..." heißen: "... auf der Registerkarte Ereignis ..."!

S. 71 unten

Statt "Anhang A" muss es heißen: "Anhang B"!

S. 77

In der Abbildung 2.5 muss es heißen: "Zu einem Kunden... ...gehören... ...keiner oder mehrere... ...Kundenaufträge". Hier und an allen anderen Stellen schließt "keiner oder mehrere" immer "einen" mit ein. Es müsste ganz genau genommen also heißen "...keiner, einer oder mehrere..."!

S. 78

Der Satz " Der Kreis heißt „null“ oder „kein“ " ist leider etwas missverständlich formuliert. Damit meine ich wirklich nur den Kreis selber - nicht seine Benutzung im logischen Modell. Ich wollte damit ausdrücken, dass ich die Symbolik "Kreis - Strich - Krähenfuss" sehr anschaulich finde. Bei seiner Benutzung im logischen Modell symbolisiert der Kreis tatsächlich die Kardinalität "kein oder ein"!

S. 126 unten

Zwischen Punkt 3 und 4: Es klingt etwas verrückt - aber wenn Sie Access 2007 oder 2010 verwenden, sollten Sie als Dateityp "Microsoft Office Access-Datenbanken (Format 2002-2003)" wählen! Das hängt mit einer "Verbesserung" in der 2007er/2010er Version zusammen, die keine Verbesserung ist. Ich gehe auf S. 144 unten / S. 145 oben und auf S. 303 genauer darauf ein. (siehe insb. der Tipp auf S. 303 unten!)

S. 128 unten

Statt "Sie können bei Standardwert auch eine Funktion wie heute() eingeben." muss es heißen: "Sie können bei Standardwert auch eine Funktion wie Jetzt() eingeben."

S. 140

Vorletzter Absatz auf dieser Seite: Wenn Sie das genau so wie beschrieben machen, werden Sie mit Access 2003 bemerken, dass Ihr Listenfeld hinterher nicht mehr funktioniert. Das gilt allerdings nur für Access 2003. Die Ursache hierfür ist etwas verzwickt:
Bis zur Version 2003 legen die Assistenten den für das jeweilige Steuerelement (in diesem Fall das Listenfeld) erforderlichen Code als VBA-Code an. Ab 2007 werden sog. "eingebettete Makros " erzeugt (siehe dazu S. 144 unten und 145 oben und S. 303!!). Sie sehen das, wenn Sie sich im Eigenschaftenfenster der Liste das Register "Ereignis" anschauen.
Ein eingebettetes Makro funktioniert auch noch, wenn der Name des Steuerelements (in diesem Fall also der Liste) geändert wird. Für eine VBA-Prozedur gilt das nicht. Man könnte jetzt meinen, dass dann ein Makro "besser" sei - ich denke aber genau das Gegenteil (siehe dazu S. 144/145, S. 303 und S. 318!). Sie sollten das von mir empfohlene Umbenennen der Liste also lieber erst einmal sein lassen. Sie können das dann noch nachholen, wenn Sie im Buch die Seiten 303 und 318ff gelesen haben!

S. 142, Tabelle 3.2

"Abfrage aktualisieren" heißt in Access 2010 "Aktualisierungsabfrage" und "Abfrage löschen" heißt "Löschabfrage"!

S. 271

Im SQL-Script für die Tabelle tblRaum muss es statt "geb_id_f LONG," heißen: "geb_id_f LONG NOT NULL,"!

S. 296

Hier ergänzen Sie bitte in Ihrem Buch folgenden Text:

Im Datenmodell (Abbildung 8.2) sehen Sie eine besondere Merkwürdigkeit: Eine Beziehnung der Tabelle tblSachgebiet zu sich selbst. Ich hatte diese Konstruktion im Kapitel 2 unter der Überschrift "Hierarchische Ordnungen" ausführlich erläutert. Sehen Sie sich dazu bitte die Darstellung einer solchen "Selbstbeziehung" in Access an ("Datenbanktools" / "Beziehungen"). Dort wird Ihnen eine Tabelle tblSachgebiet_1 auffallen. Das ist keine neue Tabelle, sondern lediglich eine Kopie der Tabelle tblSachgebiet. Sie entsteht, indem Sie einfach die Tabelle tblSachgebiet ein zweites mal per drag&drop in das Beziehungsfenster hineinziehen. Access setzt dann automatisch die Endung "_1" hinter den Tabellennamen. Anschließend können Sie eine Beziehung zwischen tblSachgebiet und tblSachgebiet_1 herstellen - also eine Beziehung einer Tabelle zu sich selbst! Vorher müssen Sie natürlich bei der Datenmodellierung dafür sorgen, dass die Tabelle tblSachgebiet einen entsprechenden Fremdschlüssel enthält - in diesem Fall ist es das Feld "obersachgebiet".

S. 367 oben

In dem ALTER TABLE-Befehl muss es statt "fk_yyy" heißen: "fk_tblXxx_yyy"! (Erläuterung: Der Name des Constraints muss datenbankweit eindeutig sein!)

S. 384

Auf Nachfrage eines Lesers habe ich mal ein "Kochrezept" für die Umsetzung der von mir im Buch nur kurz erwähnten Benutzerberechtigungen geschrieben:

• In der Datenbank gibt es irgendeine Tabelle (z.B. tblPerson, tblMitarbeiter, tblMitglied, ...), in der Personen gespeichert werden, die mit der DB arbeiten sollen.
• in der Personentabelle (z.B. "tblPerson") zwei Spalten "per_loginname" und "per_passwort" anlegen
• Tabelle tblGruppe anlegen mit Nutzergruppen (z.B. "Chef" und "Mitarbeiter")
• m:n-Beziehung tblGru_Per zwischen tblPerson und tblGruppe, denn EINE Person kann u.U. auch in MEHREREN Gruppen sein! Es könnte ja z.B. eine Gruppe geben, die neue Mitarbeiter eintragen darf und eine Gruppe, die Rechnungen erstellen darf. Dann kann es aber Personen geben, die beides dürfen.
• zwei Textfelder "Name" und "Passwort" im Startformular
• Passwort: Eigenschaften / Daten / Eingabeformat: "Kennwort"! (Dann werden bei der Eingabe nur Sternchen angezeigt)
• alle Buttons des Startformulars beim Öffnen deaktivieren
• Nach der Eingabe des Namens und des Passwortes durch den Nutzer wird herausgesucht, in welchen Gruppen der eingeloggte Benutzer ist
• eintragen aller Gruppen in ein unsichtbares Listenfeld im Startformular
• ACHTUNG: Deaktivieren des "Schließen"-Buttons des Startformulars!! Das Startformular muss immer offen bleiben, damit man jederzeit in dem Listenfeld nachsehen kann, in welchen Gruppen der Benutzer ist.
• Entsprechend der Gruppenzugehörigkeit des Benutzers werden bestimme Buttons des Startformulars aktiviert - nämlich alle die, die Formulare öffnen, die der Benutzer zunächst einmal überhaupt sehen darf.
• Ob er im geöffneten Formular Daten bearbeiten oder löschen oder neu anlegen darf, wird ebenfalls wieder sofort beim Öffnen des Formulars entschieden. Dazu sieht man per VBA in dem unsichtbaren Listenfeld im Startformular nach, zu welchen Gruppen der Benutzer gehört. Je nachdem, was welche Gruppe darf, werden die Buttons "neu", "speichern", "löschen" aktiviert oder deaktiviert. Außerdem können auch einzelne Textfelder oder List- bzw. Kombo-Boxen aktiviert oder deaktiviert werden.
• Was welche Gruppe darf kann man "hard codieren", also direkt im VBA-Code schreiben (z.B. If gru_name="Chef" Then cmdNeu.Activate=True Else cmdNeu.Activate=False). Eleganter und flexibler wird das Ganze, wenn man auch diese Rechte in Tabellen hinterlegt. Dazu müsste es eine Tabelle tblFormular und eine Tabelle tblSteuerelement geben (1:n-Beziehung dazwischen) und eine m:n-Beziehung zwischen tblGruppe und tblSteuerelement: EINE Gruppe hat Rechte an MEHREREN Steuerelementen; An EINEM Steuerelement haben MEHRERE Gruppen Rechte. Dann muss man immer beim Öffnen eines Formulars nachschauen, in welchen Gruppen der angemeldete Benutzer ist und an welchen Steuerelementen er welche Rechte hat. Dazu müsste man sich eine entsprechende Prozedur schreiben, die in jedem Formular aufgerufen werden kann.
ACHTUNG: Dabei kann es zu Rechtekonflikten kommen, d.h. der Benutzer darf z.B. als Mitglied der "Gruppe A" neue Kunden anlegen, als Mitglied der "Gruppe B" darf er es nicht. Dann müsste natürlich das weiter gehende Recht aus "Gruppe A" Vorrang haben. Das müsste man bei der Programmierung berücksichtigen!

S. 21

Der Verweis auf die "Microsoft Forms 2.0 Object Library" macht offenbar Probleme. Einerseits findet man in verschiedenen Quellen im Internet Hinweise darauf, dass diese Library Abstürze verursachen kann. Andererseits finden etliche Leser diesen Verweis überhaupt nicht in der Liste der möglichen Verweise, so dass sie ihn auch nicht aktivieren können. Meine Tests haben - bisher jedenfalls - ergeben, dass meine Beispielanwendungen auch ohne diesen Verweis funktionieren. Bitte probieren Sie es einfach - sollte es daraufhin Fehlermeldungen geben, so teilen Sie es mir bitte mit und ich werde mich darum kümmern.

Noch ein Hinweis zu diesem Thema für Leute, die diese Library trotzdem benutzen wollen oder müssen - sie aber in der Liste der möglichen Verweise nicht finden: Die Datei, in der sich diese Library befindet, heißt "FM20.DLL" und befindet sich im Ordner WINDOWS/system32!

S. 60/61

Die Abbildungen 1.22 und 1.23 sind falsch - das hier sind die richtigen Abbildungen: 1.22 und 1.23

S. 61 unter der Abbildung

Statt
"Sie sehen jetzt die Daten, die das Formular Mannschaften kennt: Die beiden Tabellen TRAINER und MANNSCHAFT. Das Formular kennt aber nun nicht automatisch alle Felder dieser beiden Tabellen, sondern nur diejenigen, die in der horizontalen Liste darunter erscheinen."
muss dort stehen:
"Sie sehen jetzt die Daten, die das Formular Mannschaften kennt: Die Tabelle MANNSCHAFT. Das Formular kennt aber nun nicht automatisch alle Felder dieser Tabelle, sondern nur diejenigen, die in der horizontalen Liste darunter erscheinen."

S. 69

In der ersten Zeile des zweiten Absatzes muss es statt "... auf der Registerkarte Daten ..." heißen: "... auf der Registerkarte Ereignis ..."!

S. 77

Der Satz " Der Kreis heißt „null“ oder „kein“ " ist leider etwas missverständlich formuliert. Damit meine ich wirklich nur den Kreis selber - nicht seine Benutzung im logischen Modell. Ich wollte damit ausdrücken, dass ich die Symbolik "Kreis - Strich - Krähenfuss" sehr anschaulich finde. Bei seiner Benutzung im logischen Modell symbolisiert der Kreis tatsächlich die Kardinalität "kein oder ein"!

S. 100 unten

Statt "auf der »1«-Seite der 1:n-Relation" muss dort stehen: "auf der »n«-Seite der 1:n-Relation"

S. 101 oben

Statt "und dieses ist wiederum Oberbegriff für »Mathematik«." muss dort stehen: "und dieses ist wiederum Oberbegriff für »Chemie«."

S. 113/114 und 356/357

Der Tipp mit den Reservespalten ist doch nicht so clever, wie ich dachte. Vergessen Sie ihn bitte einfach und ersetzen Sie die Seiten 113/114 und 356/357 durch diese hier: Seite 113/114 und Seite 356/357

S. 124 unten

Zwischen Punkt 3 und 4: Es klingt etwas verrückt - aber wenn Sie Access 2007 verwenden, sollten Sie als Dateityp "Microsoft Office Access-Datenbanken (Format 2002-2003)" wählen! Das hängt mit einer "Verbesserung" in der 2007er Version zusammen, die keine Verbesserung ist. Ich gehe auf S. 144 oben und S. 295 genauer darauf ein.

S. 126 Mitte

Statt "Sie können bei Standardwert auch eine Funktion wie heute() eingeben." muss es heißen: "Sie können bei Standardwert auch eine Funktion wie Jetzt() eingeben."

S. 139

Vorletzter Absatz auf dieser Seite: Wenn Sie das genau so wie beschrieben machen, werden Sie mit Access 2003 bemerken, dass Ihr Listenfeld hinterher nicht mehr funktioniert. Das gilt allerdings nur für Access 2003. Die Ursache hierfür ist etwas verzwickt:
Bis zur Version 2003 legen die Assistenten den für das jeweilige Steuerelement (in diesem Fall das Listenfeld) erforderlichen Code als VBA-Code an. Ab 2007 werden sog. "eingebettete Makros " erzeugt (siehe dazu S. 144 oben und S. 295). Sie sehen das, wenn Sie sich im Eigenschaftenfenster der Liste das Register "Ereignis" anschauen.
Ein eingebettetes Makro funktioniert auch noch, wenn der Name des Steuerelements (in diesem Fall also der Liste) geändert wird. Für eine VBA-Prozedur gilt das nicht. Man könnte jetzt meinen, dass dann ein Makro "besser" sei - ich denke aber genau das Gegenteil (siehe dazu S. 144 und S. 295!). Sie sollten das von mir empfohlene Umbenennen der Liste also lieber erst einmal sein lassen. Sie können das dann noch nachholen, wenn Sie im Buch die S. 295 gelesen haben!

S. 266

Im SQL-Script für die Tabelle RAUM muss es statt "GEB_KEY long," heißen: "GEB_KEY long not null,"!

S. 295 unten

Der Tipp funktioniert leider NICHT für die eingebetteten Makros, die vom Steuerelement-Assistenten ab der Access-Version 2007 erzeugt werden! Deshalb sollten Sie stattdessen den Tipp befolgen, den ich Ihnen hier auf dieser Webseite zu S. 124 gebe!

XYZ_KEY:

Ich lerne ja auch dazu - vor allem durch meine Aktivitäten bei www.office-loesung.de. Und dort habe ich u.a. gelernt, dass man die Primärschlüssel und Fremdschlüssel anders benennen sollte - nicht beide XYZ_KEY, sondern den Primärschlüssel xyz_id und den Fremdschlüssel xyz_id_f. In der dritten Auflage habe ich das korrigiert!

S. 59/60

Die Abbildungen 1.22 und 1.23 sind falsch - das hier sind die richtigen Abbildungen: 1.22 und 1.23

S. 60

Statt
"Sie sehen jetzt die Daten, die das Formular Mannschaften kennt: Die beiden Tabellen TRAINER und MANNSCHAFT. Das Formular kennt aber nun nicht automatisch alle Felder dieser beiden Tabellen, sondern nur diejenigen, die in der horizontalen Liste darunter erscheinen."
muss dort stehen:
"Sie sehen jetzt die Daten, die das Formular Mannschaften kennt: Die Tabelle MANNSCHAFT. Das Formular kennt aber nun nicht automatisch alle Felder dieser Tabelle, sondern nur diejenigen, die in der horizontalen Liste darunter erscheinen."

S. 98 oben

Statt "auf der »1«-Seite der 1:n-Relation" muss dort stehen: "auf der »n«-Seite der 1:n-Relation"

S. 122 Mitte

Statt "Sie können bei Standardwert auch eine Funktion wie heute() eingeben." muss es heißen: "Sie können bei Standardwert auch eine Funktion wie Jetzt() eingeben."

S. 110/11 und S. 331/332

Der Tipp mit den Reservespalten ist doch nicht so clever, wie ich dachte. Vergessen Sie ihn bitte einfach und ersetzen Sie die Seiten 113/114 und 356/357 durch diese hier: Seite 113/114 und Seite 356/357

Buch-CD der ersten Auflage

Beim Herstellen der Buch-CD für die erste Auflage ist leider ein Fehler passiert - die pdf-Datei mit der Liste wichtiger Standardaktionen (/Buch/KapA/Anhang_WichtigeStandardaktionen.pdf) lässt sich nicht ausdrucken. Hier die druckbare Version der zweiten Auflage zum Download!

XYZ_KEY:

Ich lerne ja auch dazu - vor allem durch meine Aktivitäten bei www.office-loesung.de. Und dort habe ich u.a. gelernt, dass man die Primärschlüssel und Fremdschlüssel anders benennen sollte - nicht beide XYZ_KEY, sondern den Primärschlüssel xyz_id und den Fremdschlüssel xyz_id_f. In der dritten Auflage habe ich das korrigiert!