Hallo Leute,
ich habe wieder ein Problem.
In meinem Formular habe ich ein Unterformular. Wenn ich das Hauptformular aufrufe springt der Courser in die letzte Zeile des Unterformular welches ich als Endlosformular angelegt habe. Was auch so sein soll. Auch wenn ich ein neues Endlosformular aufrufe (über das Hautformular), springt der Courser in die Letzte Zeile. Ist auch soweit alles richtig. Den Code für den Courser habe bei Ereignis unter ,,beim Anzeigen" als VBA angelegt
Nun das Problem, wenn ich jetzt feststelle das ich mich in der Zeile davor Verschrieben oder etwas Vergessen habe komme ich nicht mehr an die Zeile ran. Und Löschen lässt sie sich auch nicht. Habe ich den Code vielleicht unter ein falsches Ereignis eingetragen, oder muss ich noch etwas zu dem Code schreiben. So dass die Zeilen davor zum nachträglichen Bearbeiten oder Löschen erreichbar werden
Private Sub Form_Current()
DoCmd.GoToRecord , , acNewRec
End Sub
Hallo,
bei GotoNewRecord geht Access in den Eingabemodus. Wenn Du Esc drückst, sollte wieder eine Eingabe in den anderen Zeilen möglich sein.
Beste Grüße
Andreas
Hallo,
Form_Current() ist hier völlig ungeeignet. Damit erzeugst Du eine Endlosschleife und kommst nie aus dem letzten Datensatz. Auch mit ESC kommst Du aus der Endslosschleife nicht raus.
Denn das Ereignis wird bei jedem Datensatzwechsel ausgeführt, wenn Du einen anderen DS auswähslt, greift das Ereignis wieder und Du landest wieder in einem neuen DS. Und das jedesmal wenn ein anderer DS gewählt wird.
Nimm mal das Ereignis "Beim Öffnen" (Form_Open)
Hallo,
danke euch beide für eure Antwort
Aber eure Vorschläge führen leider nicht zum Erfolg.
@andreas deine Antwort mit ESC klappt nicht wie MzKIMu schon schrieb.
@MzKIMu
aber deine Idee ist schon besser, hat nur den Hacken das wenn ein neuer DS gewählt wird Funktioniert es nicht mehr.
Hallo,
Zitathat nur den Hacken das wenn ein neuer DS gewählt wird Funktioniert es nicht mehr.
Was funktioniert dann nicht mehr ?
Wenn man zu einer Zeile "springen" kann, dann kann das Ziel eines Sprunges auch eine andere Zeile sein - außer man blockiert das selbst durch eigene Maßnahmen, die Du Dir ansehen solltest.
Im Normalfall liegt der Fokus bei einem neu geöffneten Formular auf dem ersten Datensatz.
DoCmd.GoToRecord , , acNewRecEin neuer Datensatz soll erst ein Datensatz werden (passiert mit Speicherung). Das ist etwas anderes als der letzte Datensatz, nur die Eingabezeile liegt nun mal unten.
Hallo Leute,
@ MzKIMu
Wenn ich das so mache wie du vorgeschlagen und ich das Formular Aufrufe springt der Courser in die untere Eingabezeile. Nur wenn ich ein anderes Gerät (Datensatz) auswähle, dann steht der Courser in der ersten Zeile und nicht in der unteren Zeile. Und wenn ich das so mache wie ich Beschrieben habe kann ich ein anderes Gerät (Datensatz) aufrufe springt der Courser wieder in die letzte Zeile. Aber wie gesagt ich kann dann in der Zeile davor nicht mehr ändern.
@ebs17 Es sind keine Felder im Formular gesperrt. Den Code den du da Vorschlägst habe ich ja schon beim Anzeigen hinterlegt. Aber das klappt nicht so richtig.
Ich habe keinen Code vorgeschlagen, sondern Deinen zitiert. Dadurch sollte acNewRec herausgestellt werden, um ein Verständnis des Aufrufes zu fördern.
Sowie um die Aussage von Klaus zu wiederholen: Das Ereignis Form_Current tritt ein, wenn ein beliebiger Datensatz den Fokus erhält, also auch bei jeden anderen Datensatzwechsel. Mit dem Ereignis wird die Ereignisprozedur ausgeführt.
Falls Du also auf einen anderen Datensatz "springst", schickt Dich Deine Ereignisprozedur unmittelbar zurück auf den neuen Datensatz. Dein Codedreizeiler ist also ein glattes Eigentor. Wenn man also trockene Füße möchte, sollte man als Erstes aus der Pfütze heraustreten.
Erst Sinnieren, dann Aktionieren.
Hey Eberhard,
Ok dann habe ich das Falsch gelesen. Aber hast du eventuell eine Idee zur Lösung meines Problems.
Habe mal ein teil der DB angehängt zur besseren Verständigung.
Hallo,
und jetzt solltest Du mal noch erklären, was Du jetzt eigentlich willst.
PS:
Warum sind keine Beziehungen angelegt ?
Warum wird für die Verknüpfung von Hafo und Ufo nicht der Primärschlüssel genutzt (der ist dazu da) ?
In die Reparaturtabelle gehört der Primärschschlüssel der Herstellertabelle ind nicht die InterneNr.
Eigentlich ist die Herstellertabell die Gerätetabelle, für den Hersteller wird eine extra Tabelle benötigt und die jetzige Herstellertabelle (die dann die Gerätetabelle wird) geört ein Fremdschlüssel zum Hersteller.
Verschrottet, Verkauf als ja/Nein ist überflüssig, Du hast ja jeweils ein Datum.
Die Prüfungen wiederholen sich ja und geehören demzufolge in eine extra Tabelle.
Betriebstunden mit Datum , ebenfalls extra Tabelle.
Die DB hat einige handwerkliche Fehler, die korrigiert werden sollten, bevor es zu spät ist.