Datensatz springen nicht möglich

[Svensation]

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

[Svensation]

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

[Knobbi38]

Hallo,

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

Knobbi38

[Svensation]

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.

[Doming]

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

[Knobbi38]

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.

[Svensation]

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

Sie dürfen in diesem Board keine Dateianhänge sehen.

[PhilS]

So, 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.

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?

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.

[Bitsqueezer]

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

[Knobbi38]

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.

[Svensation]

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

Sie dürfen in diesem Board keine Dateianhänge sehen.

[Bitsqueezer]

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

[MzKlMu]

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.

[PhilS]

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.

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.

[Bitsqueezer]

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