Hallo Experten!
ich versuche gerade eine Prozedur zu schreiben, mit dem ich einen Teilstring verändern will.
Meine Prozedur lautet:
Private Sub AuswJ1()
Dim Y As String
Dim ys As String
Dim db As DAO.Database
Dim rst As DAO.Recordset
Dim z As Integer
Set db = CurrentDb()
Set rst = db.OpenRecordset("tblAuswJahr_1", dbOpenDynaset) 'Set rstQ = dbe.OpenRecordset("tblAusw")
db.Execute "DELETE FROM tblAuswJahr_1" '<- Zieltabelle wird geleert
db.Execute " INSERT INTO tblAuswJahr_1" & " SELECT * " & "FROM tblAusw"
'-------------------------------------------------------------------------------------
Y = DateSerial(Year(Date), 12, 31)
Debug.Print Y
ys = "_" & Year(Y) + 1
Debug.Print ys
Do While Not rst.EOF
For z = 0 To rst.Fields.Count - 1
Debug.Print z
rst.Edit
rst.Fields("KWBenAusw") = Replace(rst.Fields("KWBenAusw"), "_2017", ys)
rst.Update
Next z
rst.MoveNext
rst.Close
Set rst = Nothing
Loop
End Sub
Bei einer Tabelle mit nur einem Wert funktioniert sie. Aber das ist ja nicht der Zweck...Im Anwendungsfall mit einer umfangreichen Tabelle bekomme ich den Fehler 3197. Andere Nutzer würden auf den Datensatz zugreifen, was nicht stimmt. 'rst.Edit' wird beim Debugging markiert. Ist das Problem iwie zu lösen? :( Vielen Dank für eure Hilfe!!!
Beste Grüße,
Knopf
Hallo,
da braucht es doch kein VBA (und kein Recordset). Das kann eine Aktualisierungsabfrage kurz und schmerzlos.
Was soll da überhaupt geändert werden, beschreibe mal das Ziel des Codes, ich steige da nicht ganz durch, was willst Du durch was ersetzen (Replace) ?
Private Sub AuswJ1()
On Error GoTo e
With DBEngine(0)(0)
.Execute "DELETE FROM tblAuswJahr_1", dbFailOnError
.Execute "INSERT INTO tblAuswJahr_1 SELECT * FROM tblAusw", dbFailOnError
.Execute "UPDATE tblAuswJahr_1 SET KWBenAusw = " & _
"Replace(KWBenAusw, '_2017', '_2018')", dbFailOnError
End With
Exit Sub
e:
MsgBox "Fehler-Nr.: " & Err & vbCrLf & vbCrLf & Err.Description
End Subwirkt auf mich solider.
Hallo Knopf,
Abgesehen von den besseren Lösungen von Klaus und Lachtaube,
der Hinweis warum dein Code nicht funzt.
Es liegt daran, dass das rst.Close
Set rst = Nothing zu früh kommt. Das muss unter das Loop
rst.Close
Set rst = Nothing
gruss ekkehard
Hallo! Vielen Dank, das habe ich gesucht! Die db.Engine Anweisung kannte ich noch gar nicht :/...Das bringt mich auch zu meiner nächsten Frage:
Ich erstelle eine Prozedur um Exceldateien zu bearbeiten und dann zu importieren. Es sind mehrere Dateien und ich würde es so machen:
Datei 1 wählen
Datei 1 bearbeiten
Datei 1 importieren
Datei 2 wählen
Datei 2 bearbeiten
Datei 2 importieren
Datei 3 ... usw
Gibt es auch eine Möglichkeit gleich alle Dateien anzuwählen und dann zu bearbeiten, bzw. ist das so sinnvoll oder schneller?
Vielen Dank für eure Tipps :)
Es hängt wohl davon ab, was das Bearbeiten beinhaltet.
Ansonsten ist es oft üblich, das oder die Excel-Blätter (temporär) mit dem Access-Frontend zu verknüpfen und danach mittels Anfügeabfrage(n) die Daten in die entsprechende(n) Tabelle(n) zu befördern.
Hallo Lachtaube!
Du meinst das Aufteilen der Datenbank in Front-End und Back-End oder? (Damit hatte ich bisher noch nicht zu tun, Danke für den Tipp)
Die Excel Tabellen werden systematisch von einem anderen Programm erzeugt und haben zusammengefügte Zellen etc. Diese muss ich vor dem Import löschen sowie bei den Benennungen Punkte durch Striche ersetzen und so.
Wenn ich dich richtig verstanden habe, würde ich diese Exceltabellen ins Back End importieren und eine Verknüpfung zum FrontEnd erzeugen?
lg
Die Aufgabe hört sich ja fürchterlich an. Kann, darf oder soll das andere Programm keine datenbankgerechte Struktur als Export liefern?
Das ist irgendein Programm von SAP...wenn es was anderes können soll als die Standardausgabe dann kann ich es gleich vergolden....
Ich frage mich ja immer, warum man bereits in SAP gespeicherte Daten noch einmal in einem anderen Programm aufbrühen muss ?! Hat man das Personal zu wenig in SAP geschult oder fehlt es an SAP-Zusatzmodulen mit irgendwelchen Funktionalitäten?
Nun gut - die SAP-Gui exportiert Berichte, u. a. auch in Textform, womit man sich den (Um-)weg via Excel schon einmal ersparen kann. Beim Einlesen von Textdaten müssten diese dann halt zeilenweise geparst werden, was sich bei bekannten Strukturen durch relativ wenig Code (ich schätze einmal 20-30 VBA-Zeilen) bewerkstelligen lässt.
Okay danke werde das mal in Erfahrung bringen.