Datensatz springen nicht möglich

[PhilS]

man führt ja gerade eine Lookup-Tabelle ein, um die String-Wiederholung zu vermeiden. Wenn Du einen davon umbenennen mußt, dann mußt Du das per Cascade Update weiterleiten, ansonsten manuell machen.
Das passiert bei IDs nicht - einmal vergeben, werden sie nie mehr verändert (zumindest sollte es so sein, wenn man es ordentlich macht).

Da hast du mich falsch verstanden. Ich meine schon richtige Text-Schlüssel, z.B. sowas: B0C2PDKM8R (ist eine ASIN).
D.h. die Wahrscheinlichkeit einer Änderung ist genauso groß wie bei einem rein numerischen Schlüssel.

Es mag ganz seltene Ausnahmen geben, aber i.d.R. wird man schnell feststellen, daß es keinerlei Vorteile gibt, einen Text-Schlüssel zu verwenden.

Die nicht ganz so seltene Ausnahme ist der deutlich geringere visuelle Platzbedarf. Außerdem kann man mit Text-Werte auch Schlüssel erzeugen, die sich ein Mensch (wahrscheinlich) einfacher merken kann.
Beides sind natürlich keine zwingenden Gründe, dass man diese Schlüssel dann auch für Beziehungen innerhalb einer DB verwenden muss.

[Bitsqueezer]

Hallo Phil,

doch, ich habe Dich schon richtig verstanden. Auch die ASIN oder ähnliche Keys eignen sich als PK nicht, im Gegensatz zu einer 4-Byte Int hast Du hier schon 10 Byte. Und ein PK, der nicht als FK eingesetzt wird, macht auch nicht viel Sinn, entsprechend gibt es die Wiederholung in einer oder mehreren anderen Tabellen.

Nicht zuletzt kommt dazu, daß ein PK i.d.R. als Clustered Index angelegt wird, also verwendet man normalerweise einen Schlüssel, der immer aufsteigend ist. Der Clustered Index legt die physikalische Reihenfolge fest, und wenn das bei Access zwar nur bei "Komprimieren & Reparieren" neu sortiert wird, passiert das auf einem DB-Server dann bei Wartungen (also gemeint sind automatische Wartungsjobs des Servers). Das belastet alles die Performance, da auch beim Sortieren der Indizes alles umsortiert werden muß. Bei einer Auto-ID wird einfach hinten drangeschrieben.

Und so weiter.

Also: Nicht machen. Gibt wirklich so gut wie keine Ausnahme, außer vielleicht bei extrem kleinen Lookup-Tabellen, wo solche Nachteile nicht in's Gewicht fallen. Aber auch hier: Mit einer ID ist man immer auf der sicheren Seite. Ich habe das auch schon so gemacht, PKs als alphanumerisch mit sehr kurzen Texten, habe es später aber immer bereut und das Design wieder korrigiert.

Keine Ahnung, was Du mit "visuellem Platzbedarf" meinst - eine ID wird in sehr vielen Fällen nicht mal irgendwo zu sehen sein. Außer man arbeitet direkt auf Tabellen, aber das machen wir doch nicht, hm?..

Entsprechend muß sich hier auch niemand irgendwas merken. Wir sind ja hier nicht in Excel, wo man irgendwas lesen können muß.

Gruß

Christian

[Svensation]

Dann versuche ich mein Problem noch einmal genauer zu beschreiben.

Wenn ich im Formular "Auftraege" einen neuen Datensatz erfasse kann ich sämtliche Angaben machen. Wenn ich diesen dann aber oben rechts mit dem Button "Speichern / Öffnen Neuer" beenden möchte kommt folgende Fehlermeldung:

Sie können nicht zu dem angegebenen Datensatz springen.
Möglicherweise befinden Sie sich am Ende eines Records

Ab und zu gelange ich dann in die MS Visual Basic Ansicht, wo er mir mitteilt, dass irgendetwas mit folgendem Code nicht in Ordnung ist:

Code [Auswählen] Erweitern

Private Sub Form_BeforeUpdate(Cancel As Integer)
    If Not Me.NewRecord Then Me.Aenderungsdatum = VBA.Date()
Das hat bis anhin aber immer alles funktioniert und jetzt stürtzt das Programm ab da der Befehl nicht ausgeführt werden kann. Im VB hat aber ganz bestimmt nie jeamnd etwas angepasst...

Vielleicht helfen diese Infos weiter.

[MzKlMu]

Hallo,
es liegt an der Abfrage für das Formular. Mit dieser Abfrage können keine bestehenden Datensätze bearbeitet werden (diese werden ohnehin nicht angezeigt) und keine neuen Datensätze angelegt werden. Die Abfrage ist nicht aktualisierbar.

Ich kann Dir da auch nicht helfen, weil keine Zusammenhänge erkennbar sind. Ob die in der Abfrage angelegten Verknüpfungen richtig sind, vermag ich auch nicht zu beurteilen.
Ich glaube, die Datenbank ist von einem richtigen überlegten Datenmodell noch weit entfernt. Es sind auch keine Beziehungen (im Beziehungsfenster) angelegt, was für weitere Probleme sorgt.
Siehe auch meine kleine Anmerkung in #12.
Sind in der Originaldb auch keine Beziehungen angelegt ?

Eine derart umfangreiche Datenbank lässt sich nicht funktionstüchtig aufbauen ohne die Grundlagen einer relationalen Datenbank zu beachten.

[Knobbi38]

Hallo Sven,

was soll das? Die von dir beschriebene Schaltfläche führt ein "embedded" Makro aus, welches wiederum das Makro "Speichern / Öffnen Neuer Verfasser erfassen" ausführen möchte. Kontrolliere doch bitte mal deine Beispiele, bevor du hier irgend etwas hochlädst. Wie sollen wir wissen, was da abläuft, wenn die wesentlichen Angaben fehlen?

Es ist auch nicht sinnvoll, ein Steuerelement mit "Speichern / Öffnen Neuer Verfasser erfassen"  zu benennen und , was noch viel schlimmer ist,  dem aufgerufenem Makro denselben Namen zu geben. Wie kommt man auf so etwas?

Im Übrigen solltest du solche Konstrukte komplett vermeiden und deine Makros durch gewöhnlichen VBA-Code ersetzen. Bei Makros ist die Bereitschaft, Hilfestellungen zu geben, sehr gering.

Zusätzlich gehört in jede Klasse/Modul mindestens die Anweisung "Option Explicit", mal so ganz nebenbei. Dann kannst du versuchen, den VBA Code zu kompilieren und erst wenn das fehlerfrei durchläuft, kannst du dich auf weitere Fehlersuche begeben - das ist quasi immer der erste Schritt.

Gruß Knobbi38

PS:
Das Startformular hast du immer noch in deinem Beispiel eingetragen.  😒

[Bitsqueezer]

Hallo Klaus,

also bei mir war die Abfrage aktualisierbar, auch neue Datensätze konnten angelegt werden.

Ich habe aber auch nur diese beiden Felder (wie angegeben) eingegeben.

Generell ist aber immer sinnvoll, in einer Abfrage immer nur eine Tabelle zu verändern, auch wenn Access hier vieles toleriert.

Gruß

Christian

[PhilS]

im Gegensatz zu einer 4-Byte Int hast Du hier schon 10 Byte.

Diese Rechnung scheint offensichtlich, ist aber nicht richtig.
Um etwa die gleiche Anzahl der möglichen positiven Werte eines Int32 mit einen Textschlüssel abzubilden brauchst du nur 6 Byte, weil du 36 verschiedene Möglichkeiten (Zahlen und Buchstaben, case-insensitive) für jedes Zeichen hast anstatt nur 10.

Mit "visuellem Platzbedarf" meine ich, dass du beim obigen Beispiel nur 6 Zeichen anstatt 10 brauchst, um eine Kunden-, Auftrags-, Rechnungs-, oder Sonstwasnummer auf ein Blatt Papier (oder dessen digitales Äquivalent) zu drucken.

Ich will das hier (OT) in diesem Thread jetzt gar nicht weiter diskutieren. Ich bin im wesentlichen ja ganz deiner Meinung, nur glaube ich dass es viel, viel mehr Ausnahmen gibt, bei denen ein Textschlüssel, nach ausgiebiger Evaluierung der Umstände, eine gute Wahl sein kann.