Hallo Leute,
ich brauche eure Hilfe bei meiner Anfänglichen Problem, siehe Betreff.
Ich habe in einer Formular ein Unterformular erstellt, wodrin der Inhalt einer Tabelle angezeigt wird. Diese möchte ich mit einem Klick auf einer Schaltfläche den ausgewählten Datensatz in entsprechende Textfelder hinzufügen. Durch diese Schaltfläche möchte ich quasi den Datensatz umändern und mit dem SQL-Befehl "Update ... " abspeichern.
Mein Quelltext dazu sieht folgendermaßen aus:
Dim rs As Recordset
Set rs = Me.frmUnterformular.Form.Recordset
rs.Refresh
If Not (rs.EOF And rs.BOF) Then
With rs
Me.txtAuftragID = .Fields("AuftragID")
Me.txtDatum = .Fields("Datum")
Me.txtPersonalID = .Fields("PersonalID")
Me.txtObjektID = .Fields("ObjektID")
Me.txtSchichtID = .Fields("SchichtID")
Me.txtUhrzeitBeginn = .Fields("UhrzeitBeginn")
Me.txtUhrzeitEnde = .Fields("UhrzeitEnde")
End With
End If
Das alles funktioniert soweit zwar gut, aber manchmal, wenn ich im Unterformular keinen Datensatz auswähle sondern statt dessen die Textfelder manuel mit neuen Datensatz ausfülle und diese mit einer anderen Schaltfläche in die Datenbank mit der SQL-Befehl "Insert Into ... " abspeicher und später dann im nächsten Schritt wieder im Unterformular einen anderen Datensatz markiere um den Datensatz ändern zu können, bekomme ich unterschiedliche Fehlermeldungen. Manchmal stürtzt sogar das Programm ab, so dass ich dann quasi den VBA-Code Beenden oder Debuggen muss.
Einer der Fehlermeldungen ist solches:
Fehler beim Kompilieren:
Methode oder Datenobjekt nicht gefunden
Kann mir jemand hierbei helfen?
Die Ursache ist genau an der "If"-Bedingung. Das Programm kommt mit dem ".EOF" und ".BOF" nicht klar obwohl das selbstverständlich ist.
Gibt es eine andere Möglichkeit wie ich das noch lösen könnte?
Für jede hilfe wäre ich euch sehr Dankbar.
Ich habe sämtliche Videos bei Youtube und sämtliche Foren in Google durchforstet aber leider konnte ich keine vernünftige Lösung finden.
Vielleicht liegt es an meiner Anfänglichen situation. Vielleicht habt ihr mir da eine bessere Lösungsvorschlag.
Dies ist meine letzte Hoffnung!
Ich bedanke mich schon mal im Voraus für die Mühe.
Mit freundlichen Grüßen
Daniel
Hallo,
warum arbeitest Du nicht einfach mit gebundenen Formularen ?
Da braucht es weder Update noch Insert geht alles automatisch ohne Code.
Da dürften sich auch Deine Probleme erledigt haben.
Anfänger programmieren zu Beginn viel zu viel.
Hallo,
deklariere rs As DAO.RecordSet und kompiliere den Code VOR dem Testen.
Was das betrifft:
ZitatManchmal stürtzt sogar das Programm ab, so dass ich dann quasi den VBA-Code Beenden oder Debuggen muss.
das ist kein Absturz, sondern eine Unterbrechung der Code-Ausführung, weil ein Laufzeit-Fehler aufgetreten ist.
PS:
Ein Recordset kennt keine Refresh-Methode.
Zitat von: MaggieMay am Oktober 01, 2015, 15:30:29
Hallo,
deklariere rs As DAO.RecordSet und kompiliere den Code VOR dem Testen.
Was das betrifft:ZitatManchmal stürtzt sogar das Programm ab, so dass ich dann quasi den VBA-Code Beenden oder Debuggen muss.
das ist kein Absturz, sondern eine Unterbrechung der Code-Ausführung, weil ein Laufzeit-Fehler aufgetreten ist.
PS:
Ein Recordset kennt keine Refresh-Methode.
Hallo MaggieMay,
ich danke dir für die Unterstützung.
Habe deine Deklaration rs As DAO.RecordSet befolgt und bekomme immer noch fehler.
Der Fehler ist:
Das Objekt ist ungültig, oder es ist nicht mehr festgelegt.
Wenn ich die Datensätze einmal durch diesen Prozess durchlaufen habe und ein 2. Mal durchlaufen möchte, kommt dieses Problem zustande.
Wie kann ich noch einen Datensatz von einem Unterformular entnehmen und in einzelenen Textfelder hinzufügen?
Das mit "Refresh" habe ich rausgenommen.
Bitte um Hilfe!
MfG
Daniel
Hallo,
poste doch mal den kompletten Code der Prozedur, in der der Code-Teil steht....
Zudem bin ich auch der Meinung wie Klaus, dass ein gebundenes Formular besser angebracht ist. Oder handelt es sich hier etwa um ein solches?
Hallo DF6GL,
leider kann ich es nicht mit einem gebundenes Formular machen. Es soll halt so wie oben beschrieben gemacht werden. Das ist nämlich die Voraussetzung.
Mein Gesamter Code lautet folgendermaßen:
Private Sub btnEdit_Click()
Dim rs As DAO.Recordset
Set rs = Me.frmUnterformular.Form.Recordset
On Error GoTo ErrorHandler
If Not (rs.EOF And rs.BOF) Then
With rs
Me.txtAuftragID = .Fields("AuftragID")
Me.txtDatum = .Fields("Datum")
Me.txtPersonalID = .Fields("PersonalID")
Me.txtObjektID = .Fields("ObjektID")
Me.txtSchichtID = .Fields("SchichtID")
Me.txtUhrzeitBeginn = .Fields("UhrzeitBeginn")
Me.txtUhrzeitEnde = .Fields("UhrzeitEnde")
End With
End If
ExitProcedure:
Exit Sub
ErrorHandler:
MsgBox err.Description, vbExclamation, "Update-Error:"
Resume ExitProcedure
End Sub
Zitatleider kann ich es nicht mit einem gebundenes Formular machen
Wie kommen denn die Daten ins Unterformular?
Der Code ist fehlerfrei kompilierbar?
@ all, die helfen wollen
wegen Crosspostings wird dieses Thema aktuell im MS-Office-Forum fortgeführt.
Zitat von: MaggieMay am Oktober 01, 2015, 22:51:19
Zitatleider kann ich es nicht mit einem gebundenes Formular machen
Wie kommen denn die Daten ins Unterformular?
Der Code ist fehlerfrei kompilierbar?
Hallo MaggieMay
ich habe für die Unterformular im "Eigenschaftenblatt -> Daten -> Herkunftsobjekt" die entsprechende Tabelle dafür auserwählt. Daher kommen die Daten ins Unterformular an.
Und die zweite Zeile mit dem Fragezeichen hast du übersehen? ;-)
Oder ist das Problem inzwischen gelöst? Wie weit bist du denn in dem anderen Forum gekommen?
Zitat von: MaggieMay am Oktober 02, 2015, 14:24:37
Und die zweite Zeile mit dem Fragezeichen hast du übersehen? ;-)
Oder ist das Problem inzwischen gelöst? Wie weit bist du denn in dem anderen Forum gekommen?
Ubs stimmt, sorry ...
Also denke ich schon das der Code fehlerfrei kompilierbar ist.
Denn ich speicher sie ab, klicke auf das "play" knopf oben und den Dialog der danach erscheint schließe ich. Anschließend öffne ich das Formular und teste das ganze ...
Also da kam ich auch nicht weit. Habe paar kleinigkeiten ausprobiert was als Vorschlag kam aber bis jetzt ist noch nichts gelöst worden :-(
Bin echt da am verzweifeln.
ZitatAlso denke ich schon das der Code fehlerfrei kompilierbar ist.
Du bist echt witzig! Das sollst du nicht denken, sondern überprüfen. (-> Debuggen -> Kompilieren)
Außerdem hattest du selbst das Auftreten von Kompilierfehlern anfangs erwähnt. Wie hast du sie beseitigt?
ZitatBin echt da am verzweifeln.
Da hilft wohl nur noch das Hochladen einer Beispiel-DB, damit man sich das mal genauer anschauen kann.
Hallo,
als letzten Hinweis:
Zitat"leider kann ich es nicht mit einem gebundenes Formular machen"
Wenn es sich um ungebundene Formulare handelt, so gibt es dort keine Recordset- und Recordsetclone-Eigenschaften und demzufolge auch keine Möglichkeit zu deren Verwendung...
Hi,
dann hast du dies hier wohl überlesen:
Zitatich habe für die Unterformular im "Eigenschaftenblatt -> Daten -> Herkunftsobjekt" die entsprechende Tabelle dafür auserwählt. Daher kommen die Daten ins Unterformular an.
Es ist doch so, dass das Hauptformular ungebunden ist, das Unterformular aber nicht. Nun soll auf Button-Klick der aktuelle DS aus dem UF ins HF geholt und dort geändert werden können. Von dieser Vorgehensweise weiterhin abzuraten, wo es doch der erklärte Wunsch des TE ist, finde ich wenig sinnvoll.
Ich warte jetzt auf eine Beispiel-DB mit Bedienungsanleitung. Das muss man jetzt einfach mal mit eigenen Augen sehen.
Zitat von: MaggieMay am Oktober 02, 2015, 15:31:50
ZitatAlso denke ich schon das der Code fehlerfrei kompilierbar ist.
Du bist echt witzig! Das sollst du nicht denken, sondern überprüfen. (-> Debuggen -> Kompilieren)
Außerdem hattest du selbst das Auftreten von Kompilierfehlern anfangs erwähnt. Wie hast du sie beseitigt?
ZitatBin echt da am verzweifeln.
Da hilft wohl nur noch das Hochladen einer Beispiel-DB, damit man sich das mal genauer anschauen kann.
Ach so lol ... Stimmt, habe es nun kompiliert und bekam so kein Fehler raus.
Na gut, dann baue ich das gleiche in abgespeckter Version nach um euch das zur Verfügung zu stellen.
MfG
Daniel
Zitat von: MaggieMay am Oktober 02, 2015, 16:27:49
Hi,
dann hast du dies hier wohl überlesen:
Zitatich habe für die Unterformular im "Eigenschaftenblatt -> Daten -> Herkunftsobjekt" die entsprechende Tabelle dafür auserwählt. Daher kommen die Daten ins Unterformular an.
Es ist doch so, dass das Hauptformular ungebunden ist, das Unterformular aber nicht. Nun soll auf Button-Klick der aktuelle DS aus dem UF ins HF geholt und dort geändert werden können. Von dieser Vorgehensweise weiterhin abzuraten, wo es doch der erklärte Wunsch des TE ist, finde ich wenig sinnvoll.
Ich warte jetzt auf eine Beispiel-DB mit Bedienungsanleitung. Das muss man jetzt einfach mal mit eigenen Augen sehen.
Okay ich baue sie gerade in abgespeckter Version nach. Hoffe ihr habt soweit etwas Geduld.
MfG
Daniel
Hallo Leute,
nun füge ich in die Anlage eine abgespeckte Version meiner Access-DB.
Da werdet ihr die Ursache entdecken und mich vielleicht besser verstehen.
Leider musste ich die Datei Zippen, da sie knapp 2000 kb groß war und hier ist nur die hälfte erlaubt. Hoffe es macht euch keine umstände.
Da nun auch das Zippen hier noch mehr beschränkt ist (wie dämlich), habe ich die Zipdatei in 2 Dateien gesplittet. Ich lade zuerst die 1. und danach folgt die 2. Datei. Bitte beides erst runter laden und danach entpacken.
Allerdings ist mir bei der Erstellung ein kleiner Fehler unterlaufen, den ich vergebens gesucht habe. Und zwar, wenn man im UF einen DS selektiert hat und dann die Schaltfläche "Bearbeiten" klickt, werden die Uhrzeiten nicht korrekt übernommen. Woher die Uhrsache nun entstanden ist, konnte ich nicht herraus finden.
Ich hoffe ihr könnt mir nun helfen.
MfG
Daniel
Hier ist die 2. Datei zum runter laden.
habe den Format manipuliert. Normalerweise hieß die datei "Datenbank2.z01" und ich musste sie nun in "Datenbank2.zip" umbenennen. Also auch bitte hier drauf achten ...
Wie bescheuert von diesem Forum gemacht, wirklich ... !!!
Bedanke mich im Voraus für euren Verständnis.
MfG
Daniel
Zitat von: MaggieMayVon dieser Vorgehensweise weiterhin abzuraten, wo es doch der erklärte Wunsch des TE ist, finde ich wenig sinnvoll.
Nun, zwischen erklärtem Wunsch und (Irr-)Glauben könnte man wohl differenzieren:
http://www.ms-office-forum.net/forum/showpost.php?p=1697555&postcount=33Zitat von: CrashbreakerWenn man aber in der Tabelle einige Datensätze ändern möchte, dann soll es nicht im Unterformular passieren, sondern in den jeweiligen Textfeldern (ungebundene Feldern) ...
Weil sonst hätte man direkt alles in der entsprechenden Tabellen gemacht. Das ist aber nicht der Sinn eines Formulars. Man nimmt Datensatz / Datensätze, man bearbeitet die und speichert die wieder in die jeweilige Tabelle(n) ...
Freunde: Ihr (ich eingeschlossen) habt den Sinn eines Formulars nicht verstanden! Wenn man nicht umständlich alles hin und her schiebt, programmiert man nicht, sondern betreibt allenfalls Firlefanz ...
Ein Hinweis darauf, dass, wenn man im aktuellen Anzeigeformular nicht editieren will, man statt dessen ein (gebundenes) Anfügen-/Editierformular verwenden könnte, an das man nur die ID des ausgewählten Datensatzes übergeben könnte, verpufft dann eben so, weil es ja programmatisch hochintellektuell (und fehlerwahrscheinlich) sein soll.
Viel Spaß dann noch.
Zitat von: ebs17 am Oktober 02, 2015, 18:24:42
Freunde: Ihr (ich eingeschlossen) habt den Sinn eines Formulars nicht verstanden! Wenn man nicht umständlich alles hin und her schiebt, programmiert man nicht, sondern betreibt allenfalls Firlefanz ...
Ein Hinweis darauf, dass, wenn man im aktuellen Anzeigeformular nicht editieren will, man statt dessen ein (gebundenes) Anfügen-/Editierformular verwenden könnte, an das man nur die ID des ausgewählten Datensatzes übergeben könnte, verpufft dann eben so, weil es ja programmatisch hochintellektuell (und fehlerwahrscheinlich) sein soll.
Viel Spaß dann noch.
Öhm, jetzt bitte noch einmal für Access-Anfänger?
Wie würde das aussehen mit:
Zitatstatt dessen ein (gebundenes) Anfügen-/Editierformular verwenden könnte, an das man nur die ID des ausgewählten
Datensatzes übergeben könnte,
Bitte um Erklärung!
MfG
Daniel
Übrigens:
Hier könnt ihr meine Access-Datei direkt runterladen.
http://i-sa.de/access/Datenbank2.accdb (http://i-sa.de/access/Datenbank2.accdb)
Das obige war sehr lästig.
MfG
Daniel
ZitatWie würde das aussehen ...
Du verwendest das Formular, das Du als Unterformular verwendest, oder ein ähnliches mit der gleichen Datenherkunft, bzw. bei Vorliegen einer nicht aktualisierbaren Abfrage als Datenherkunft die Tabelle, für die es zu Datensatzeditierungen kommen soll:
' Editieren bei ausgewähltem Datensatz => über ID
DoCmd.OpenForm "JenesFormular", , , "ID = " & Me.ID
' Datensatz neu erzeugen
DoCmd.OpenForm "JenesFormular", , , , acFormAdd
Entsprechende Editierungen landen erst in der Tabelle, wenn gespeichert wird, und ganz sicher nicht unmittelbar.
//Edit
unter Reaktion auf Hinweis von MaggieMay (Unterformular ist Tabelle):
Unter Formular/Unterformular verstehe ich genau und wörtlich ein Formular und nicht eine eingeklebte Tabelle.
Zitat von: Crashbreaker am Oktober 02, 2015, 18:19:20
Wie bescheuert von diesem Forum gemacht, wirklich ... !!!
Sorry, aber du beherrscht die Grundregeln nicht: Zuerst wird die Access-DB komprimiert und erst dann gezippt!
Du solltest dich also besser informieren, ehe du dich derart weit aus dem Fenster lehnst.
Und was das betrifft:
ZitatIch warte jetzt auf eine Beispiel-DB mit Bedienungsanleitung.
Wo bleibt die Bedienungsanleitung? Gefragt ist nach der Aktionsfolge, die zum Fehler führt.
Nachtrag:
Was als erstes auffällt:
- du setzt kein Formular sondern eine Tabelle als Unterformular ein
- eine modulweit deklarierte Variable kann nicht so ohne weiteres mehrfach verwendet werden
- das Recordset-Objekt sollte nach Benutzung wieder geschlossen werden
- die Auswahl des aktuellen Datensatzes im Unterformular zur Bearbeitung im Hauptformular funktioniert nicht - was hast du da geändert?
Hallo!
@MaggieMay: warum soll das Formular-Recordset geschlossen werden?
Bezüglich Datensatz-Auswahl: Wenn man Recordsetclone verwendet, ist dessen Datensatzzeiger meist an erster Stelle.
Der ursprüngliche Code mit Form.Recordset statt Form.RecordsetClone hätte schon gepasst. (Unabhängig vom umständlchen Änderungsablauf ;) - aber man kann ja zuerst den nicht funktionierenden Code richtigstellen und dann trotzdem einen anderen Ablauf verwenden.)
Da die Daten des ausgewählten Datensatzes im Unterformular verwendet werden sollen, könnte man auch direkt auf die Controls zugreifen:
With Me.frmUnterformular.Form
Me.txtAuftragID = .Controls("AuftragID")
Me.txtDatum = .Controls("Datum")
Me.txtPersonalID = .Controls("PersonalID")
Me.txtObjektID = .Controls("ObjektID")
Me.txtSchichtID = .Controls("SchichtID")
Me.txtUhrzeitBeginn = .Controls("UhrzeitBeginn")
Me.txtUhrzeitEnde = .Controls("UhrzeitEnde")
'Ändere die Beschriftung der Schaltfläche "Speichern"
Me.btnAdd.Caption = "Aktualisieren"
'Deaktiviere Schaltfläche "Bearbeiten"
Me.btnEdit.Enabled = False
' ...
Me.txtDatum.Tag = "UPDATE"
End With
Anm.: der eigentlichen Fehler ist (wie bereits im ms-office-forum erwähnt) das Schließen des Workspace-Objekt, das auch vom Formular-Recordset verwendet wird.
Set wks = DBEngine.Workspaces(0)
...
trans_ExitProcedure:
'Clean up
wks.Close ' <--- das darf nicht geschlossen werden, da es verwendet wird
Set dbC = Nothing
Set wks = Nothing
mfg
Josef
Hi,
ZitatDa die Daten des ausgewählten Datensatzes im Unterformular verwendet werden sollen, könnte man auch direkt auf die Controls zugreifen
das ist hier wohl der entscheidende Hinweis.
Aber (
sorry) der Vorschlag zum Einsatz eines Workspace-Objekts zur Aktualisierung eines einzelnen Datensatzes ist hier doch wohl ein wenig "überdimensioniert". Eine schlichte Aktualisierungsabfrage sollte genügen.
(
Abgesehen davon, dass man das auch ganz anders lösen könnte, aber das wollen wir bitte nicht noch einmal wiederkäuen!)
PS:
Zitatwarum soll das Formular-Recordset geschlossen werden?
Natürlich nicht das Recordset des Unterformulars, sondern das temporäre Recordset-Objekt.
Das scheint aber dasselbe zu sein wie bspw. bei
Set db = CurrentDB
...
db.Close
was natürlich auch nicht "funktioniert" im Sinne von "schließe" (=beende) die aktuelle DB.
Zugegeben, ich habe nicht weiter darüber nachgedacht, hatte nur im Sinn, dass man Objekte nach der Benutzung generell wieder freigeben sollte, im Sinne von "sauberer" Programmierung.
Hallo Leute,
ich danke euch sehr, dass ihr die Datei euch genauer angeschaut habt.
Ihr habt auch schöne Beiträge geleistet, doch nun bin ich etwas durcheinander. Was genau ist nun jetzt die Ursache und wie behebe ich das? Wie muss ich nun vorgehen?
Ja das stimmt, es tut mir leid. Es gab bei der Erläuterung meinerseitsher ein missverständnis. Ich hätte euch erwähnen müssen, dass mein Unterformular eine Tabelle beinhaltet und keine Formularelemente. Das lag an meinem Unerfahrenheit bzgl. Access. Habe mich zu sehr auf meinem Problem fixiert und das tut mir in der Hinsicht leit.
Hi,
mein Vorschlag wäre: vergiss Workspaces und Recordsets (vorübergehend) und setze den oben geposteten Code von Josef mit dem Direktzugriff auf die Controls des Unterformulars ein.
Zitat von: MaggieMay am Oktober 05, 2015, 12:59:23
Hi,
mein Vorschlag wäre: vergiss Workspaces und Recordsets (vorübergehend) und setze den oben geposteten Code von Josef mit dem Direktzugriff auf die Controls des Unterformulars ein.
Wow tatsächlich.
Dank Josefs beispiel hat es funktioniert. Aber habe somit die If Anweisung weg gelassen.
Wie kann ich die Überprüfung genau denn machen?
Was genau willst du denn überprüfen? Ob das Unterformular überhaupt Datensätze enthält? Oder ob der Datensatzanzeiger evtl. auf einem neuen Datensatz steht?
Das kannst du folgendermaßen machen:
If Me.frmUnterformular.Form.RecordSet.RecordCount = 0 OR Me.frmUnterformular.Form.NewRecord Then
MsgBox "Kein aktueller Datensatz!"
Exit Sub
End If
Die Verwendung des Else-Zweiges für den restlichen Code wäre dem Exit natürlich vorzuziehen, hier nur der Einfachheit halber.
Sorry, aber ich muss da nochmal etwas loswerden.
Das Thema CrossPosting wurde ja bereits angesprochen, aber du betreibst es munter weiter.
Was ich aber gar nicht verstehe ist, dass du hier eine Lösung präsentiert bekommst (ohne darauf zu antworten!), an anderer Stelle das Thema aber noch stundenlang weiter treibst.
Mein Eindruck dabei ist: Viele Helfer erhöhen nicht unbedingt die Qualität, weil ein Anfänger durch den permanent stattfindenden Input (sowie auch dessen Inhalt) leicht überfordert ist.
Warum also tust du dir das an?
Zitat von: MaggieMay am Oktober 05, 2015, 22:50:53
Sorry, aber ich muss da nochmal etwas loswerden.
Das Thema CrossPosting wurde ja bereits angesprochen, aber du betreibst es munter weiter.
Was ich aber gar nicht verstehe ist, dass du hier eine Lösung präsentiert bekommst (ohne darauf zu antworten!), an anderer Stelle das Thema aber noch stundenlang weiter treibst.
Mein Eindruck dabei ist: Viele Helfer erhöhen nicht unbedingt die Qualität, weil ein Anfänger durch den permanent stattfindenden Input (sowie auch dessen Inhalt) leicht überfordert ist.
Warum also tust du dir das an?
Hallo MaggieMay,
ich bin nicht überfordert, wirklich nicht. Ich musste gestern spät Nachmittag plötzlich raus, weil ich einen sehr wichtigen Anruf bekommen habe. Daher sorry das ich dir/euch kein Feedback geben konnte.
Ich bin auch sehr Dankbar auf allen Hilfen hier, auch deinem. Bin deshalb noch nicht auf deinen Vorschlag gekommen, weil ein anderes Problem vorhanden war, was in einem anderen Forum bereits ausdiskutiert wird und die nicht ganz gelöst wurde. Es tut mir leid, dass es dir einen falschen eindruck erweckt hat. Aber auf deinem Vorschlag werde ich garantiert noch zurück kommen.
Hinzu kommt, dass mich sehr positiv bewundert hat, dass ihr in beiden Forums aktiv seit - was ich ja zur Anfangszeit nicht gewusst habe. Daher dachte ich, dass ihr das mitverfolgt, da ihr das ja mehrfach angesprochen habt.
ZitatDaher dachte ich, dass ihr das mitverfolgt
So ist es, zumindest was mich betrifft. Seit ich den Hinweis auf den Parallel-Thread erhielt, schaue ich halt ab und zu, ob es wohl was neues gibt. ;-)
BTW:
Das mit dem Hinweis auf die mögliche Überforderung war nicht abwertend gemeint, es ist aber doch so, dass du selbst gelegentlich von "
Verzweiflung" und "
Verwirrung" geschrieben hast, was ich sehr verständlich finde bei einem Anfänger in Sachen VBA.
Zitat von: MaggieMay am Oktober 05, 2015, 14:57:13
Was genau willst du denn überprüfen? Ob das Unterformular überhaupt Datensätze enthält? Oder ob der Datensatzanzeiger evtl. auf einem neuen Datensatz steht?
Das kannst du folgendermaßen machen:
If Me.frmUnterformular.Form.RecordSet.RecordCount = 0 OR Me.frmUnterformular.Form.NewRecord Then
MsgBox "Kein aktueller Datensatz!"
Exit Sub
End If
Die Verwendung des Else-Zweiges für den restlichen Code wäre dem Exit natürlich vorzuziehen, hier nur der Einfachheit halber.
Deine 2. Frage traf eher. Habe das eingebaut und zusätzlich mit der Hilfe von Josef im anderen Forum habe ich das ganze soweit doch noch lösen können.
Aber die Entwicklung geht weiter und vielleicht bekomme ich weitere Fragen noch, wo ihr mir dann eventuell erneut helfen könnt.
Bin echt froh, dass ich euch allen kennen gelernt habe.
Dankeschön, ehrlich bin dank euch sehr erleichtert.
Gruß
Daniel
Zitat von: MaggieMay am Oktober 06, 2015, 13:27:53
ZitatDaher dachte ich, dass ihr das mitverfolgt
So ist es, zumindest was mich betrifft. Seit ich den Hinweis auf den Parallel-Thread erhielt, schaue ich halt ab und zu, ob es wohl was neues gibt. ;-)
BTW:
Das mit dem Hinweis auf die mögliche Überforderung war nicht abwertend gemeint, es ist aber doch so, dass du selbst gelegentlich von "Verzweiflung" und "Verwirrung" geschrieben hast, was ich sehr verständlich finde bei einem Anfänger in Sachen VBA.
Ja du hast recht. Dankeschön ...
Könnte vor freude euch allen einzeln umarmen :) :) :)