Office: (Office 2010) Zu neuestem Datensatz springen

Hallo,

ich füge in meiner DB oft Datensätze über ein modales Formular ein, welches über ein Endlosform aufgerufen wird. Wenn ich dieses Formular verlasse und wieder im aufrufenden Form bin wird ein Requery des endlosformulars ausgeführt und der erste Datensatz im Endlosformular ist markiert.

Meine Idee:
Alle Datensätze haben eine ID vom Typ Autowert. Also springe ich einfach zu dem Datensatz, der hier die höchste Nummer aufweist. Allerdings weiss ich mal wieder nicht, wie ich das bewerkstellige. Goto.Last funktioniert nicht, das die Sortierung unterschiedlich sein kann.

Kann mir jemand auf die Sprünge helfen?

:)

 

Du köntest den höchsten Wert der ID ermitteln.

 

Da käme es ja auf eine zusätzliche Variante nicht an. Du könntest nach ID absteigend sortieren.

 

Hallo und danke für die Antworten.

@Eberhard: Da hatte ich mich unklar ausgedrückt. In den unterschiedlichen Endlosformularen kommen unterschiedliche Sortierungen vor, aber die Sortierung in jedem Endlos-Formular sollte nicht geändert werden.

@Elmar: Die Funktion hat mir gefehlt *Smilie

 

Hallo nochmal,

Ich habe nun folgenden Code erstellt:
Code:

Mit call opnDetail() wird das Detailformular mit einem leeren Datensatz modal geöffnet. Schliesse ich das Formular läuft der Code auch richtig weiter. Die ermittelte ID entspricht der des neu erstellten Datensatzes. Nach dem Requery sehe ich den Datensatz im Formular, aber das Programm bricht mit dem Hinweis ab, dass ich nicht zu dem gewählten Datensatz springen kann.

EDIT: Auch eine Änderung zu DoCmd.GoToRecord acDataForm, "frmEmployeeOV", acGoTo, lngNewRSID
bringt keine Änderung.

Was habe ich falsch gemacht?
EDIT: Mein Fehler ist, dass ich zu Datensatz 30 springe. In der Tabelle sind aber nur 10 (dem Testen geschuldete Lücken im Autowert).

Also sollte die Frage eher lauten, wie springe ich zum Datensatz mit der ID 30?

 

Code:

oder, wenn du dich schon im frmEmployeeOV befindest:
Code:

maike

 

Das war des Rätsels Lösung. Danke!

 

Nur einer der Gründe, warum ich nie den Autowert nutze, sondern die "laufende Nummer" automatisch selbst vergebe. Das ist schon mehrfach auf Unverständnis gestoßen, da einige den Autowert vehement verteidigen.
Wenn der jedoch erstmal Probleme macht, dann meist richtig.

 

Hallo,
wenn man einen Autowert vergibt, so dient der meist als Primärschlüssel und hat sonst keinen Sinn. Und Lücken spielen da keine Rolle. Im Regelfall ist der Autowert auch gar nicht sichtbar.
Warum soll ich mir da die Mühe machen und nur zum Zwecke eines Primärschlüssels eine eigenen LfdNr erstellen. Zumal das in einer Mehrbenutzerumgebung auch seine Tücken hat.
Ich gehöre daher zu den Verteidigern des Autowertes. *grins

Und der in #5 gezeigte Code würde auch mit einer eigenen LfdNr (ohne Lücken) zu einem Fehler führen, da der Code nicht zu einer bestimmten Nummer springt sondern den Datensatzzeiger verschiebt und somit auch nicht den gewünschten Datensatz anzeigt.

 

Das ist wohl so etwas wie eine "Glaubensfrage". Ich persönlich finde ihn ziemlich nervig z.B. wg. der nicht Zurücksetzbarkeit. Aber als ID, für die ich ihn genau so nutze wie von Klaus beschrieben, finde ich ihn ausgesprochen praktisch. Da muss man sich um nichts kümmern :-)

 

Servus,
hier mal ein Tipp von mir, um von Anfang an Probleme zu vermeiden.
Wer die Gelegenheit hat, eine DB "from Scratch" aufzubauen,
muss in jeder Tabelle einen PK (Primärschlüssel, Autowert) verwenden.
Dieser PK ist ein Access-interner Zähler und darf nicht für irgendwelche
Nutzungsdaten verwendet werden.
Der PK taucht während der Entwicklungsphase in Formularen sichtbar auf
und kann später unsichtbar gemacht werden.
Der PK dient zusammen mit einem FK (Fremdschlüssel, Zahl, Typ Longinteger)
der Erstellung von 1:n oder m:n Beziehungen.
Auch der FK darf nur als Access-interner Schlüssel verwendet werden und nicht
als irgendein Nutzungsdaten-Zählfeld.
Das garantiert optimalsten Umgang im Bereich der rel. Integrität .

Damit aber auch Ausnahmen möglich sind, hat Access auch sehr viele
Möglichkeiten, von dieser Normalität abzuweichen.
Man sollte aber vermeiden, die Ausnahmen von Anfang an schon zur Normalität zu erklären.

 

Hallo
ich habe dir auch noch was

Prüfen ob Erster / Letzter / Neuer Datensatz in Formular
Möchte man in einem Formular wissen, welcher Datensatz (Erster / Letzter oder ein Neuen) im Moment angezeigt wird kann dieses durch folgende
Befehle erreicht werden.
Erläuterungen gibt's unter den Stichworten
"CurrentRecord" und "NewRecord" in der Online-
Hilfe(OH).

Code:

 

Hallo,
@Pawel Popolski

Auch der Autowert ist in gewissen Grenzen manipulierbar, wenn man das will oder mal braucht. Man kann auch Lücken wieder füllen, wenn es sein muss. Auch auf einen Anfangswert setzen ist möglich. Also so ganz ist man dem Autowert nicht ausgeliefert.

Praktisches Beispiel:
Wenn ich in einer Detailtabelle z.B. einen Eintrag "Noch nicht zuordenbar" brauche, so verwende ich dafür gern den Autowert 0, der lässt sich per Anfügeabfrage problemlos als Datensatz anlegen.

 

Man muss jetzt aber nicht Dogmen formulieren, die dann als solche nicht zutreffen und an der Realität vorbeigehen.

In einer Verknüpfungstabelle einer m:n-Beziehung, die soll es ja desweilen auch geben, schwimmt ein Autowert-PK hilf- und funktionslos herum, es sei denn, man kann ihn durch fortgeschrittenere Abfragekonstruktionen doch desweilen nutzen, dann aber nur in der Form der Eindeutigkeit und nicht in der Form des Primärschlüssels.

Datenmodellierung hat nun wenig mit Access speziell zu tun, sondern allgemein mit Datenmanagement per SQL, und das allgemeingültig für relationale Datenbanken - es gibt da weitere, die die gleiche Standardisierung nutzen.

Wer jetzt speziell für Access spielt, tut den ersten Schritt dafür, dass Access dann von "Experten" nicht als richtige Datenbank wahrgenommen wird.

 

Schließe mich Eberhards obigem Thread in jeder Hinsicht an. Nicht alle Features, die
mitgeliefert werden, müssen dogmatisch genutzt werden.
(Beispiel: Access-Makros)

Der Autowert wird seitens zahlreicher "Oracle, SQL-Server -Fans
und -Experten" in unserer Kundschaft für Access-Kinderkram gehalten und strikt abgelehnt.
Unsere eigene Lösung zur Schaffung von Eindeutigkeit läuft auch in Mehrbenutzerumgebung völlig stabil.

Zu Problemen mit dem Autowert gibts auch hier im Forum
zahlreiche Beispiele:
http://www.ms-office-forum.de/forum/...m+mit+autowert

Der Autowert hat sicherlich seine Berechtigung und wird wie man sieht
auch häufig genutzt. Kann auch mal richtig nützlich sein:
http://www.ms-office-forum.de/forum/...d.php?t=340506
Zum Aufbau von Beziehungen taugt er nicht
und zur Schaffung von Eindeutigkeit ist mir jeder Timestamp lieber.

Wollte auch keine Grundsatzdiskussion für und wieder des
Autowertes auslösen. Gab es alles schon und die Standpunkte sind
bekannt.

Wie bereits erwähnt: Muss jeder selbst wissen. *wink.gif*