Access-o-Mania

Hallo zusammen

Ich habe ein echtes Problem mit meiner Datenbank, welchei vor Jahren im Geschäft eingeführt habe und welche auch zahlreich benutzt wird. Leider kommt mir jetzt bei der Eingabe eines neuen Datensatzes die Meldung:

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

Was bedeutet das genau und wie kann ich das wiederherstellen?

Ich dachte zuerst, dass die Tabelle nun zu viele Datensätze enthält und habe einige davon gelöscht. Trotzdem kommt die Meldung. Ich bin ziemich verzweifelt...

Danke

Es Muss irgendetwas beim Formular sein, da.ich den Datensatz direkt in der Tabelle erfassen kann.

Hallo,

leider sagt meine Glaskugel so gar nichts dazu, also ein paar mehr Informationen wären eventuell hilfreich.

Knobbi38

Ich bin leider nicht so versiert. Was wäre denn ausser der Fehlermeldung wichtig zu wissen?

Ich mache die Datenerfassung über ein Formular und kann dabei sämtliche Daten problemlos erfassen. Am Ende, wenn ich die Daten speichern möchte sollte mich das System auf einen neuen Datensatz bringen, damit eine weitere Erfassung möglich ist. Dann kommt allerdings die oben erwähnte Fehlermeldung und der Vorgang wird abgebrochen.

Moin Sven,

es ist unwahrscheinlich, dass Deine Tabelle voll ist  ;)
Also schicke Deine Datenbank doch mal mit einigen wenigen anonymisierten Daten hier hoch, damit man sich das Problem mal ansehen kann.

Gruß
 Doming

So eine Meldung kann vielerlei Ursachen haben, z.B. eine nicht aktualisierbare Datenquelle, Filtereinstellungen oder schlichtweg ungültige Werte in irgendwelchen Variablen. Wie Doming schon beschrieben hat, bräuchte man eine BeispielDB mit anonymisierten Tabellen, um Beziehungen und Indexeinstellungen prüfen zu können inkl. der Beschreibung, wie der Fehler reproduziert werden kann.


Knobbi38

PS:
Bei Fehlermeldungen immer die Fehlernummer mit angeben.

Hallo zusammen

So, ich habe es endlich gesschafft eine anonymisierte und abgespeckte Version der Access Datenbank zu erstellen. Was gar nicht so einfach ist... Wäre toll, wenn mir irgendjemand helfen könnte.

Beim "fehlerhaften" Formular handelt es sich um das Formular "Auftraege".

Was ich grundsätzlich nicht begreiffe ist, dass Formulare oder Abfragen plötzlich nicht mehr funktionieren. Irgendjemand muss doch eine Änderung vorgenommen haben sonst würde das doch alles wie gewohnt laufen oder nicht?

Besten Dank

ABC.zip

Zitat von: Svensation am Juli 06, 2025, 18:26:10So, ich habe es endlich gesschafft eine anonymisierte und abgespeckte Version der Access Datenbank zu erstellen. Was gar nicht so einfach ist...

Das ist allerdings oft schwieriger als man auf Anhieb glauben möchte.
Dir ist dabei ein Fehler unterlaufen. Die Tabelle Stammnummern fehlt in deiner Beispiel-DB. Damit funktioniert die Abfrage Abfrage_Auftraege_Basiswerte nicht und es ist nicht möglich, das Problem mit dem neuen Datensatz im Formular zu untersuchen.

Was mir ansonsten auffällt: Die Tabelle Auftraege hat keinen Primärschlüssel. Das könnte evtl. ein Faktor bei deinem Problem sein.

Zitat von: Svensation am Juli 06, 2025, 18:26:10Was ich grundsätzlich nicht begreiffe ist, dass Formulare oder Abfragen plötzlich nicht mehr funktionieren. Irgendjemand muss doch eine Änderung vorgenommen haben sonst würde das doch alles wie gewohnt laufen oder nicht?

Das ist richtig.

Hatte die Auftraege-Tabelle noch nie einen Primärschlüssel, oder ist der irgendwie abhanden gekommen? - Evtl. ist das die gesuchte Änderung.

Auch externe Änderungen, z.B. wenn der Dateisystem-Ordner in dem sich die DB befindet plötzlich schreibgeschützt ist, können solche Probleme verursachen.

Hallo,

Du solltest vielleicht die Funktion erst testen vor dem Hochladen.

In Deiner Testdatenbank fehlt die Tabelle "Stammnummern", weswegen das Formular bzw. seine Abfrage nicht geöffnet werden kann. So kann man Dir auch nicht weiterhelfen.

Generell enthält die Datenbank wieder jede Menge Designfehler. Von unzulässigen Namen bis fehlender Normalisierung, fehlende Beziehungen zwischen Tabellen bis Mischabfragen für Formulareingaben alles drin.

Vom Code gar nicht zu reden, solche Wiederholungsmonster sind kaum wartbar.
Mein Tip dafür: Erstelle Dir eine Entscheidungstabelle dafür, die je nach ProduktkategorieII das Enabled/Disabled regelt, dann kannst Du das per Tabelle laden und auch per Formular eingeben.
Außerdem: Wenn man den Code 2x braucht, wiederholt man ihn nicht komplett, sondern erstellt eine Sub und ruft sie an 2 Stellen auf (mal davon ausgehe, daß beide identisch sind, habe es nicht geprüft).

Die Fehlermeldung bei Passwort-Falscheingabe geht mal gar nicht.
Und hartkodierte Passwörter in Klartext machen auch keinen Sinn.

Deine ursprüngliche Fehlermeldung bedeutet genau das, was da steht: Du versuchst irgendwo, zu einem Datensatz zu springen, der entweder nicht existiert oder zu dem nicht gesprungen werden kann. Etwa, wie ebenfalls in der Fehlermeldung steht, wenn man versucht, zum nächsten Datensatz zu springen, aber bereits bei EOF angelangt ist, also am Ende oder auf einem neuen Datensatz.

Auch Access ändert sich mit Updates, Regeln werden verschärft, die vorher zulässig waren. Also muß man seinen Code daran anpassen.
Meistens ist es aber dennoch selbsterzeugtes Problem. Davon enthält Deine Datenbank reichlich.

Gruß

Christian

Hallo Sven,

leider hast du deine abgespeckte Version nicht mehr selber geprüft. Es fehlen noch Tabellen die für eine Hilfestellung benötigt werden. Auch ist es nicht hilfreich, wenn du ein Starformular angibst, welches nicht vorhanden ist. Ein Startformular hier im Forum gibt sowieso wenig Sinn, weil sich die Helfer i.d.R. erstmal einen Überblick verschaffen möchten.

Bevor du nun einen neue Version hier hochlädst, solltest du aber schon mal ein paar Dinge verbessern:
- Beziehungen, wo sind die?
- Übliche Namenskonventionen? So etwas erleichtert die Einarbeitung und Hilfestellung
- Deine Tabellen sind nicht "ordentlich" nach den Regeln von relationalen Datenmodellen per Fremdschlüssel verknüpft. Textfelder sind dafür weniger geeignet und werden als Fremdschlüssel eher selten verwendet.
- Was ist der Unterschied zwischen Auftrag und Auftrag (vereinfacht)?
- Makros durch VBA-Code ersetzen.

Was soll eigentlich der riesige Select-Case in der Ereignisroutine ,,Form_Current"? Irgendwie scheint es eher so, als würde es sich dabei um ein Designproblem handeln, anstatt um eine vernünftige Lösung.


Gruß Knobbi38

PS:
Ich sehe gerade, daß andere dazu auch schon etwas geschrieben haben.

Besten Dank für Eure Rückmeldungen.

Eines vielleicht vorneweg. Ich bin bei weitem kein Profi und habe nur von der Schule her (was vor über 20 Jahren war...) etwas von Access mitbekommen. Dann habe ich "leider" damit begonnen eine Datenbank aufzubauen. Diese funktioniert grundsätzlich und wird auch täglich gebraut entspricht aber bei weitem keinen Richtlinien. Das bin ich mir bewusst. Das Ganze ist mir wohl ein wenig über den Kopf gewachsen...

Was ich aber durchaus mitbekommen habe ist, dass die Tabelle jeweils einen Primärschlüssel benötigt. Ich bin mir deshalb sicher, dass ich diesen auch gesetzt habe, weshalb das nicht mehr der Fall war, kann ich nicht sagen. Ich habe diesen nun wieder ergänzt. Leider kommt die Fehlermeldung weiterhin. Hier noch einige Antworten zu denjenigen Fragne, welche ich beantworten kann:

- Die Fehlernummer ist die 3021
- Der Unterschied zwischen Auftrag und Auftrag (vereinfacht) ist nur das im vereinfacht nicht alle Felder aktiv sind
  Das Formular speichtert die Daten aber in der gleichen Tabelle
- Die Tabelle "Stammnummern" habe ich noch ergänzt

@Bitsqueezer: Ja, die Fehlermeldung geht nicht, da hast du recht. Ist auch nicht wirklich ernst zu nehmen...sorry.

Ich möchte nicht zu einem Datensatz springen welcher nicht existiert sondern das System soll mich zu einem neuen, noch leeren Datensatz bringen, damit der User einen neuen Auftrag erfassen kann. Dies hat bis vor wenigen Tagen problemlos funktioniert und jetzt scheint das nicht mehr zu gehen...

Bin froh um jede Hilfe - Danke

ABC.zip

Hallo,

ich habe mal testweise "88" als "Valorensuche" eingegeben, weil es der erste Datensatz in "Basiswerte" ist und irgendeine Stammnummer, weil man ohne sie nicht speichern kann.

Speichern funktioniert, vorwärts blättern auf einen neuen Datensatz sowohl mit ">" als auch mit dem gelben Sternchen in der Datensatznavigation. Nur wenn man mit ">" nochmal weiterzublättern versucht, kommt die Fehlermeldung. Was korrekt ist.

Also ich sehe nicht, wo da Dein Problem ist. Da mußt Du schon mal exakte Anleitung geben, wie man Dein Problem nachstellen kann.

Primärschlüssel: Nein, es ist nicht zwingend nötig, einer Tabelle einen PK zu geben. Tabellen ohne PK sind Heaps, "Haufen", deren Reihenfolge unbestimmt ist. Sie sind u.U. weniger performant, je nach Größe und Verwendung. Wären sie zwingend, könntest Du keine Tabelle ohne PK anlegen.
Was man hingegen nie machen sollte: Einen Textwert als PK zu verwenden, da dieser dann in der FK-Tabelle ständig wiederholt werden muß, was genau gegen die Normalisierung verstößt. Daher am besten als PK immer eine ID mit "Auto" einstellen, was Access bei jeder neuen Tabelle sowieso schon vorschlägt. Besser aber nicht überall "ID" nennen..

Für die vielen anderen Dinge bräuchte es ganze Kapitel an Text.

Gruß

Christian

Hallo,
und der PS alleine ist ja nur die halbe Miete. Es sollten auch Beziehungen angelegt werden die auf der 1-Seite den PS nutzen. Die n-Seite ist dann ein Zahlenfeld (Long, zum Autowert passend) in den verknüften Tabellen.

Zitat von: Bitsqueezer am Juli 07, 2025, 19:16:27Was man hingegen nie machen sollte: Einen Textwert als PK zu verwenden, da dieser dann in der FK-Tabelle ständig wiederholt werden muß, was genau gegen die Normalisierung verstößt.

Es gibt keine Normalisierungsregel, die einen Text-Schlüssel verbietet.
Natürlich braucht ein Text-Schlüssel intern mehr Speicherplatz als ein vergleichbarer numerischer Schlüssel, welcher daher meist vorzuziehen ist. Ein "nie machen" würde ich daraus aber nicht ableiten.

Hallo Phil,

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).
Ein "nie machen" ergibt sich alleine daraus ganz von selbst. 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.


Gruß

Christian

Zitat von: Bitsqueezer am Juli 07, 2025, 23:11:19man 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.

Zitat von: Bitsqueezer am Juli 07, 2025, 23:11:19Es 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.

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

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:

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.

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.

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

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

Zitat von: Bitsqueezer am Juli 08, 2025, 01:00:33im 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.