Unter Access sind Sie es gewohnt, nach Lust und Laune am Entwurf einer Tabelle zu arbeiten. Probleme gibt es nur, wenn Sie einmal die Feldgröße oder den Felddatentyp ändern wollen – etwa, weil die Daten dann nicht mehr in das Feld passen könnten. Das können Sie jedoch durch einen Mausklick bestätigen und weitermachen. Beim SQL Server sieht das etwas anders aus. Relevante änderungen, die sich auf bestehende Felder beziehen, sieht das SQL Server Management Studio nicht so gern und blockiert dies – Sie müssen dann die Tabelle neu anlegen. Wer einen kleinen Trick nicht kennt, macht sich auf diese Weise viel unnötige Arbeit.
Schauen wir uns kurz ein Beispiel an: Sie haben eine Tabelle namens tblObjekte erstellt, die aus den beiden Feldern ObjektID (Datentyp int) und Bezeichnung (Datentyp varchar(255)) besteht. Der Entwurf sieht dann wie in Bild 1 aus.
Bild 1: Erster Entwurf der Tabelle tblObjekte
Nun haben Sie allerdings vergessen, einen Autowert für das Primärschlüsselfeld zu hinterlegen. Also öffnen Sie die Tabelle nochmals im Entwurf und bearbeiten die Spalteneigenschaften der Spalte ObjekttypID.
Hier wählen Sie für die Eigenschaft Identitätsspezifikation nach dem Erweitern der Eigenschaft den Wert Ja aus – die Felder ID-Ausgangswert und ID-Inkrement werden automatisch auf 1 eingestellt (siehe Bild 2).
Bild 2: Anpassen der Identitätsspezifikation
Beim Versuch, die Tabelle nach den änderungen zu speichern, schlägt allerdings fehl. Es erscheint die Meldung aus Bild 3. Diese besagt, dass die vorgenommenen änderungen eine Neuerstellung der Tabelle erfordern. Das gelingt allerdings nicht automatisch – zumindest nicht mit den standardmäßig aktivierten Optionen einer Installation des SQL Server Management Studios. Wenn man nicht genau weiterliest, ist man versucht, die Tabelle tatsächlich zu löschen und dann nochmal mit den gewünschten Einstellungen neu anzulegen.
Unter Access sind Sie es gewohnt, nach Lust und Laune am Entwurf einer Tabelle zu arbeiten. Probleme gibt es nur, wenn Sie einmal die Feldgröße oder den Felddatentyp ändern wollen – etwa, weil die Daten dann nicht mehr in das Feld passen könnten. Das können Sie jedoch durch einen Mausklick bestätigen und weitermachen. Beim SQL Server sieht das etwas anders aus. Relevante änderungen, die sich auf bestehende Felder beziehen, sieht das SQL Server Management Studio nicht so gern und blockiert dies – Sie müssen dann die Tabelle neu anlegen. Wer einen kleinen Trick nicht kennt, macht sich auf diese Weise viel unnötige Arbeit.
Schauen wir uns kurz ein Beispiel an: Sie haben eine Tabelle namens tblObjekte erstellt, die aus den beiden Feldern ObjektID (Datentyp int) und Bezeichnung (Datentyp varchar(255)) besteht. Der Entwurf sieht dann wie in Bild 1 aus.
Bild 1: Erster Entwurf der Tabelle tblObjekte
Nun haben Sie allerdings vergessen, einen Autowert für das Primärschlüsselfeld zu hinterlegen. Also öffnen Sie die Tabelle nochmals im Entwurf und bearbeiten die Spalteneigenschaften der Spalte ObjekttypID.
Hier wählen Sie für die Eigenschaft Identitätsspezifikation nach dem Erweitern der Eigenschaft den Wert Ja aus – die Felder ID-Ausgangswert und ID-Inkrement werden automatisch auf 1 eingestellt (siehe Bild 2).
Bild 2: Anpassen der Identitätsspezifikation
Beim Versuch, die Tabelle nach den änderungen zu speichern, schlägt allerdings fehl. Es erscheint die Meldung aus Bild 3. Diese besagt, dass die vorgenommenen änderungen eine Neuerstellung der Tabelle erfordern. Das gelingt allerdings nicht automatisch – zumindest nicht mit den standardmäßig aktivierten Optionen einer Installation des SQL Server Management Studios. Wenn man nicht genau weiterliest, ist man versucht, die Tabelle tatsächlich zu löschen und dann nochmal mit den gewünschten Einstellungen neu anzulegen.
Unser exklusives Angebot für Dich!
(Gilt für den Abschluss eines Jahres-Abonnements im ersten Jahr, danach 189,-/Jahr)
Hier geht’s weiter →Die ersten 4 Wochen kostenlos testen – voller Zugriff auf alle Artikel, vollständigen Code und Beispieldatenbanken. Kein Risiko: Wenn es nicht passt, kündigst Du einfach innerhalb der ersten vier Wochen.
Oder hast Du eine konkrete Frage zu Deiner eigenen Access-Anwendung?
Vielleicht stellt Deine Anwendung Dich vor eine Herausforderung, zu der Du bisher keine Lösung findest. Schlechte Performance, kein ausreichender Zugriffsschutz, Du bist unsicher über Dein Datenmodell oder Dein Code liefert unerklärliche Fehler?
In unserem kostenlosen Access-Audit schaut sich André Minhorst persönlich gemeinsam mit Dir Deine Lösung per Zoom an – und zeigt Dir, wo Datenmodell, VBA-Code, Ergonomie und Sicherheit Optimierungspotenzial bieten.
Jetzt kostenloses Access-Audit anfordern →