Juni 21, 2021, 03:53:14

Neuigkeiten:

Ist euer Problem gelöst, dann bitte den Knopf "Thema gelöst" drücken!


SQL Insert überspringt beim Speichern den nächsten Primärkey

Begonnen von Mero, Juni 03, 2021, 03:45:41

⏪ vorheriges - nächstes ⏩

Mero

Hallo zusammen,
ich bin neu in Access, ich bitte also um Nachsicht...

Über Button in einem Formular öffnet sich ein weiteres Formular, das Informationen des aktiven Datensatzes des ersten Formulars anzeigt. Die Informationen werden bearbeitet und über einen Speichern-Button als als neuer Datensatz in die Tabelle geschrieben.

Allerdings wird immer ein Primärkey "übersprungen". Das sieht dann so aus:
 Sie dürfen in diesem Board keine Dateianhänge sehen.

Ich habe es mit DoCmd.RunSQL und mit db.execute versucht, gleiches Ergebnis.
dbFailOnError zeigte dann (als ich es hinzugefügt hatte) Laufzeitfehler 3464 an, das hab ich mit der Datumsformatierung behoben.
Es wird aber immer noch ein Key übersprungen.

Die Daten werden ordnungsgemäß geschrieben, es geht mir nur um die "verloren gegangen" Primärkeys.
Keine Ahnung ob da erstmal ein Dummydatensatz geschrieben wird, der dann gelöscht wird, bevor der eigentliche Datensatz geschieben wird.
Ich konnte im Netz nichts finden.

Hier ist der Code:

Dim SQLstrInsert As String
Dim dbs As DAO.Database
Set dbs = CurrentDb()
   
SQLstrInsert = "Insert into Proben " & _
               "([Probedatum], [FSPrAID], [OBJ FS], [Probenanzahl], [von], [bis], [Informationen], [Laufende Nummer]) " & _
        "Values ('" & Format(Me.txtProbedatum, "yyyy-mm-dd") & "', '" & Me.cboArtDerProbe & "', '" & Me.txtAnzObjFS & "', " & _
                 "'" & Me.txtLetztePrAnzahl & "', '" & Me.von & "', '" & Me.bis & "', '" & Me.txtInformationen & "', " & _
                 "'" & Me.txtLaufendeNummer & "')"
     
Debug.Print SQLstrInsert
   
DoCmd.SetWarnings True
dbs.Execute SQLstrInsert, dbFailOnError
   
dbs.Close
Set dbs = Nothing


Danke für jede Hilfe

ebs17

Wie ist das Verhalten, wenn Du direkt in die Tabelle einträgst?
Je nach dem, wie die Tabelle erzeugt wurde, kann die Schrittweite des Autowertes auch abweichend von 1 sein.
Mit freundlichem Glück Auf!

Eberhard

MzKlMu

Hallo,
Zitat von: undefineddas Informationen des aktiven Datensatzes des ersten Formulars anzeigt. Die Informationen werden bearbeitet und über einen Speichern-Button als als neuer Datensatz in die Tabelle geschrieben.
Wie kommen denn die Daten zur Anzeige in das Formular ?
Wenn das ein gebundenes Formular ist, so wird doch mit der Bearbeitung ein vorhandener Datensatz geändert und dieser dann als neuer Datensatz gespeichert. Eigentlich müssten dann die Daten 2x in der Tabelle sein.

Wenn es wirklich ein gebundenes Formular ist, so ist doch aber das Insert überflüssig.

Kannst Du das mal genauer beschreiben ?
Gruß
Klaus

Mero

@ebs17
Hallo Eberhard, der Primärkey wird um 1 erhöht, wenn ich direkt in die Tabelle schreibe.

@MzKlMu
Hallo Klaus, es ist ein ungebundenes Formular, das über VBA aufgerufen wird (wenn man den eingangs erwähnten Button drückt).

Die Daten kommen über SQL Select aus der gleichen Abfrage, die auch dem Basisformular zugrunde liegt.
Über Where Kondition wird nur der eine Datensatz angezeigt, bei dem der Button gedrückt wurde.

Die einzelnen Textfelder bzw. eine Combobox werden dann gefüllt über z.B.
Forms![ProbeFestlegen]![txtPPara] = Me.txtPPar1

Und wie gesagt, es wird richtig abgespeichert. Wenn denn nicht immer ein Key übersprungen werden würde....

VG Stefan

ebs17

"Verbrauchte" Autowerte sind auch möglich, wenn man die Inhalte mehrfach gegen einen eindeutigen Index abfeuert.
Mit freundlichem Glück Auf!

Eberhard

Mero

@ebs17
aber der einzige "Kontakt" zur Tabelle ist ja bei Ausführung der SQL Insert Anweisung, zumindest soweit ich das verstehe.
Ich hab jetzt noch stundenlang weiter recherchiert und rumgebastelt, nichts funktioniert.

markus888

@Mero,
zwischen dem gezeigten Code und dem Problem besteht aus meiner Sicht kein Zusammenhang.

Ohne Test-Möglichkeit direkt in der Anwendung bleibt das ein Raten.


10 Jahre Access


PhilS

Juni 04, 2021, 10:59:58 #8 Letzte Bearbeitung: Juni 04, 2021, 11:24:28 von PhilS
Zitat von: Mero am Juni 03, 2021, 03:45:41Keine Ahnung ob da erstmal ein Dummydatensatz geschrieben wird, der dann gelöscht wird, bevor der eigentliche Datensatz geschieben wird.
Ich vermute, genau das passiert. - Aber nicht, weil Access das grundsätzlich so machen würde, sondern vermutlich, weil du in deinem gebundenem Formular (Basisformular) bereits mit der Dateneingabe begonnen hast (evtl. per VBA), diese dann abbrichst (Autowert bereits vergeben), und danach deine Anfügeabfrage ausführst.
Access DevTools - Find and Replace
Komfortables Suchen und Ersetzen in den Entwurfseigenschaften von Access-Objekten. In Abfragen, Formularen, Berichten und VBA-Code - Überall und rasend schnell!

ebs17

Neben den anderen Ergänzungen:
Zitataber der einzige "Kontakt" zur Tabelle ist ja bei Ausführung der SQL Insert Anweisung
Es ist ja nicht gezeigt, wie der Code wirklich eingesetzt wird. Ein unruhiger Finger bei einer Befehlsschaltfläche könnte zu einem Anweisungsdauerfeuer führen ...

Wenn man gegen einen eindeutigen Index arbeitet, sollte man besser erst prüfen und dann abhängig agieren.
Statt zu raten sollte man sich seiner Tabellendefinition und seiner Umgebung (Formulare, deren Codes) sehr bewusst sein und wissen, wie man arbeitet.
Mit freundlichem Glück Auf!

Eberhard

Josef P.

Juni 04, 2021, 14:23:42 #10 Letzte Bearbeitung: Juni 04, 2021, 14:33:48 von Josef P.
[etwas OT, da das mit dem Code in #1 nichts zu tun hat]

Hallo!

In einem gebundenen Formular bewirkt Me.Recordset.AddNew, dass ein Autowert "übersprungen" wird.

mfg
Josef

Mero

Juni 05, 2021, 18:32:00 #11 Letzte Bearbeitung: Juni 08, 2021, 01:58:07 von Mero
Hallo zusammen,

das Thema ist gelöst, ich finde allerdings den erwähnten Button nicht, um den Thread hier als gelöst zu kennzeichnen.

Bevor ihr jetzt gleich über mich herfallt, verweise ich auf Satz 1 meines ersten Postings ;)
Außerdem habe ich die Datenbank "geerbt", und als Neuling ist mir da was durchgegangen....

Vielen Dank für die Hinweise, besonders dass der Code ok erscheint. Das hat die Fehlersuche eingegrenzt.
Ich habe die Lösung selbst vor den Antworten von @Josef P. und @PhilS gefunden, aber beide Antworten weisen genau zum "Problem" (das eigentliche Problem sitzt aber vorm Bildschirm...)

Die Lösung:
1. Wie im Text irgendwo erwähnt, habe ich beim Start des Formulars einen SQL String erstellt und dem Formular per .Form.RecordSource zugewiesen.
Das ist nicht der eigentliche Fehler, aber vollkommen unnötig, da die Steuerelemente des Formulars die Daten ja, wie oben beschrieben, per [Forms]![formular]![Steuerelement] = Me.txtIrgendwas erhalten.

2. Durch 1. war es nun möglich, dass zwei Steuerelemente einen alten Eintrag bei "Steuerelementeinhalt" übernommen haben, der aufgrund von Namensgleichheit auch noch "gültig" war.

Nachdem die beiden Einträge entfernt waren, war alles ok. Kein "übersprungener" Key mehr.
Vielen Dank für die Hilfe, case closed.

VG Stefan