Supportnet / Forum / Datenbanken
Wert eines Feldes in einem Tabeldatensatz mit VBA (Access) ändern
Frage
Hallo,
Ich habe folgendes Problem:
in einer Access-Datenbank (Access2000) hab ich mit eim Table (TeKalk) ein
Fomular erstellt.
ich möchte nun mit einem VBA-Code die einzelnen Datensätze abfragen, Werte
übernehmen und einen neuen Wert in einen Satz auf ein bestimmes Feld eingeben.
Die Abfrage funktioniert - aber bei der Eingabe eines Wertes bekomme ich die
Meldung " Datenbank oder Object sind Schreibgeschützt". Ich kann die Ursache
nicht finden.
Wer kann mir helfen??
Das wäre schön
Der Code lautet
Private Sub Form_Load()
Dim Con As ADODB.Connection, RS As ADODB.Recordset, SQL As String
Dim AnArbWo As Double ´ AnzahlArbeitswochen
Dim ArbStunTag As Double ´ArbeitsstundenTag
Dim AbwesWo As Double ´Abwesenheitswochen
Dim IstTag As Double ´ Tage/Woche
Dim AbreStuPlan As Double ´AbrechnungsstundenPlan
Dim ArbStuIst As Double ´ArbeitsstundenIst
Dim ReisKo As Double ´ Reisekosten
Dim AbweiPlan As Double ´AbweichPlan
Dim intFak As Double ´internFaktor
Dim extFak As Double ´externFaktor
Dim MannTag As Double ´MannTage
Dim Kost As Double ´Kosten
Dim Umsa As Double ´Umsatz
Set Con = CurrentProject.Connection
Set RS = New ADODB.Recordset
RS.CursorType = adOpenKeyset
RS.LockType = adLockOptimistic
SQL = "SELECT * from TeKalk"
RS.Open SQL, Con ´ , , , adCmdText
Do While Not RS.EOF
If RS!Bez = "AnzahlArbeitswochen" Then
AnArbWo = RS!Jan
End If
If RS!Bez = "ArbeitsstundenTag" Then
ArbStunTag = RS!Jan
End If
If RS!Bez = "Abwesenheitswochen" Then
AbwesWo = RS!Jan
End If
If RS!Bez = "TageWoche" Then
IstTag = RS!Jan
End If
If RS!Bez = "AbrechnungsstundenPlan" Then
AbreStuPlan = (AnArbWo - AbwesWo) * IstTag * ArbStunTag
RS!Jan = AbreStuPlan ´Hier bricht die Routine
ab!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
End If
RS.MoveNext
Loop
RS.Close
Con.Close
End Sub
Antwort 1 von piano
Hallo
Soviel ich mich erinnere, sollte vor dem Ändern das statement "RS.Edit" und danach "RS.Update" erfolgen!
Gruß piano
Es wäre nett, wenn Du ein Feedback abgeben könntest,
ob der Lösungsvorschlag Dein Problem gelöst hat.
- probieren geht über studieren -
Soviel ich mich erinnere, sollte vor dem Ändern das statement "RS.Edit" und danach "RS.Update" erfolgen!
Gruß piano
Es wäre nett, wenn Du ein Feedback abgeben könntest,
ob der Lösungsvorschlag Dein Problem gelöst hat.
- probieren geht über studieren -
Antwort 2 von erik
Hast du die Werte in TeKalk etwa untereinander stehen? Das sieht verdächtig nach einer Excel-Tabelle aus. Die Texte, die du in RS!Bez abrufst, sollten eigentlich Spaltenüberschriften sein, und die Monate(?) wie "Jan" sind Zeilen.
Wenn das stattdessen eine Kreuztabelle ist, dann hast du die Tabelle falsch gedreht. Die Spalten sollten Zeilen sein und umgekehrt.
Falls du das entsprechend korrigieren kannst, dann reicht eine einfache Aktualisierungsabfrage, um die Berechnung durchzuführen.
Wenn das stattdessen eine Kreuztabelle ist, dann hast du die Tabelle falsch gedreht. Die Spalten sollten Zeilen sein und umgekehrt.
Falls du das entsprechend korrigieren kannst, dann reicht eine einfache Aktualisierungsabfrage, um die Berechnung durchzuführen.
Antwort 3 von moberny
Hallo Piano,
besten Dank für Deine Anregung.
Aber bei ADO gibt es das Statment Edit nicht!
Das gibt es nur bei DAO.
Ich habe es inzwischen mit DoCmd-Befehlen versucht, also ohne die Connect-Routine des ADO´s..
Es scheint , dass ich damit weiter komme. Auf neue Schwierigkeiten kann ich warten!
Hallo erik,
Du hast recht.
Bei der ursprünglichen Formularanordnung , wie Du vorschlägst, hat die Akualisierungabfrage auch funktioniert .
Aber aus Übersichtsgründen versuchte ich diese Fomularanordnung
Bei einer normalen VB6 Programmierung mit Zugriff auf Access mit einem Grid gibt es da überhaupt keine Probleme.
Aber dieses VBA - das nervt!
besten Dank für Deine Anregung.
Aber bei ADO gibt es das Statment Edit nicht!
Das gibt es nur bei DAO.
Ich habe es inzwischen mit DoCmd-Befehlen versucht, also ohne die Connect-Routine des ADO´s..
Es scheint , dass ich damit weiter komme. Auf neue Schwierigkeiten kann ich warten!
Hallo erik,
Du hast recht.
Bei der ursprünglichen Formularanordnung , wie Du vorschlägst, hat die Akualisierungabfrage auch funktioniert .
Aber aus Übersichtsgründen versuchte ich diese Fomularanordnung
Bei einer normalen VB6 Programmierung mit Zugriff auf Access mit einem Grid gibt es da überhaupt keine Probleme.
Aber dieses VBA - das nervt!
Antwort 4 von erik
In ADO braucht das Recordset keine Edit-Methode. Ändere einfach was du willst, und speichere am Ende mit der Update-Methode. Warum in deinem Fall trotzdem ein Schreibschutzfehler auftaucht, kann ich spontan nicht sagen. Evtl. hast du die Datenbank im Schreibschutzmodus geöffnet oder die Datei selbst ist schreibgeschützt? Kannst du denn andere Tabellen ändern? Bezügl. der Fehlermeldung finde ich bei Microsoft nur diese beiden Artikel:
KB304146
KB247861
Du könntest die bisherige Abfrage weiterverwenden, wenn du die Daten richtig in den Tabellen anordnest, siehe Antwort 2. Die geforderte Formularansicht müsstest du über eine Kreuztabellenabfrage hinbekommen können. Der einzige Haken dabei ist jedoch, dass die Inhalte der Kreuztabelle nicht änderbar sind.
KB304146
KB247861
Du könntest die bisherige Abfrage weiterverwenden, wenn du die Daten richtig in den Tabellen anordnest, siehe Antwort 2. Die geforderte Formularansicht müsstest du über eine Kreuztabellenabfrage hinbekommen können. Der einzige Haken dabei ist jedoch, dass die Inhalte der Kreuztabelle nicht änderbar sind.
Antwort 5 von moberny
Hallo erik,
vielen Dank für die interessanten Hinweise. Ich muss das noch genau studieren.
Ich habe inzwischen mit den DoCmd.RunCommand - Befehlen mein Ziel erreicht und glaube, dass dies im VBA doch der einfachere Weg ist. Ich habe damit einwandfreien Zugriff auf jede Reihe einer Feldspalte und kann alle Berechnungen durchführen.
Die VBA-Datenbankprogrammierung mit ADO-Connection scheint doch einige Bugs aufzuweisen, insbesondere bei Access2000, das ich verwende.
Bis dann!
moberny
vielen Dank für die interessanten Hinweise. Ich muss das noch genau studieren.
Ich habe inzwischen mit den DoCmd.RunCommand - Befehlen mein Ziel erreicht und glaube, dass dies im VBA doch der einfachere Weg ist. Ich habe damit einwandfreien Zugriff auf jede Reihe einer Feldspalte und kann alle Berechnungen durchführen.
Die VBA-Datenbankprogrammierung mit ADO-Connection scheint doch einige Bugs aufzuweisen, insbesondere bei Access2000, das ich verwende.
Bis dann!
moberny
Antwort 6 von erik
Hi moberny,
es mögen zwar überall mal Bugs lauern, aber ADO läuft unter Access 2000 immer noch stabil genug, um auch einen simplen Datenzugriff durchführen zu können, wie du es versuchst. Ich bin eher davon überzeugt, dass dein Problem hausgemacht ist. Aus der Ferne ist es allerdings schwierig, entsprechende Stolperfallen zu finden. Ich persönlich bin jedoch noch nie auf eine solche Schreibschutzmeldung gestoßen, und ich habe schon genug ADO-Zugriffe durchgeführt.
es mögen zwar überall mal Bugs lauern, aber ADO läuft unter Access 2000 immer noch stabil genug, um auch einen simplen Datenzugriff durchführen zu können, wie du es versuchst. Ich bin eher davon überzeugt, dass dein Problem hausgemacht ist. Aus der Ferne ist es allerdings schwierig, entsprechende Stolperfallen zu finden. Ich persönlich bin jedoch noch nie auf eine solche Schreibschutzmeldung gestoßen, und ich habe schon genug ADO-Zugriffe durchgeführt.
Antwort 7 von moberny
Hallo erik,
das mag ja sein, dass der Fehler hausgemacht ist, aber den Hacken habe ich trotzdem noch nicht gefunden.
Wie gesagt, ich arbeite schon lange mit ACCESS2000 im VB6 und habe keine Probleme - aber eben im VBA.
Wenn es dir Spaß macht, dann versuch´ doch meine Routine:
Erstelle eine Tabelle mit den Feldern Bez und Jan ...Dez.
Fülle die angeführten Eingaben nacheinander in das Bez -Feld.
Erstelle ein Formular mit dieser Tabelle und setze in den VBA-Code die obigen Programmzeilen ein.
Ob dann wohl dieselbe Fehlermeldung erscheint?
das mag ja sein, dass der Fehler hausgemacht ist, aber den Hacken habe ich trotzdem noch nicht gefunden.
Wie gesagt, ich arbeite schon lange mit ACCESS2000 im VB6 und habe keine Probleme - aber eben im VBA.
Wenn es dir Spaß macht, dann versuch´ doch meine Routine:
Erstelle eine Tabelle mit den Feldern Bez und Jan ...Dez.
Fülle die angeführten Eingaben nacheinander in das Bez -Feld.
Erstelle ein Formular mit dieser Tabelle und setze in den VBA-Code die obigen Programmzeilen ein.
Ob dann wohl dieselbe Fehlermeldung erscheint?
Antwort 8 von erik
Ein Test ist nicht nötig, ich begnüge mich mit dem Lesen des Codes. Dabei ist mir eben erst aufgefallen, dass du nach der Zuweisung kein Update des Datensatz ausführst? Du solltest unmittelbar nach der Zuweisung an AbreStuPlan noch die Zeile "RS.Update" ausführen. Unabhängig davon löst der angezeigte Code, so wie er jetzt dasteht, aber nicht den Fehler aus.
Du musst dich auf andere Teile der Datenbank konzentrieren. Die besagte Fehlermeldung tritt z.B. mit Abstand am häufigsten im Zusammenhang mit externen Textdateien usw. auf, siehe Google.
Über VBA solltest du dir keine weiteren Gedanken machen, daran kann es nicht liegen. ADO funktioniert unter VBA exakt genauso wie unter VB. Schließlich greifen beide auf dieselbe ADO-Objektbibliothek zu.
Du musst dich auf andere Teile der Datenbank konzentrieren. Die besagte Fehlermeldung tritt z.B. mit Abstand am häufigsten im Zusammenhang mit externen Textdateien usw. auf, siehe Google.
Über VBA solltest du dir keine weiteren Gedanken machen, daran kann es nicht liegen. ADO funktioniert unter VBA exakt genauso wie unter VB. Schließlich greifen beide auf dieselbe ADO-Objektbibliothek zu.
Antwort 9 von moberny
Das RS.update wurde von mir keineswegs vergessen. Beim zeilenweise Testen hatte ich aber festgestellt, daß die Fehlermeldung bereits in der vorangehenden Zuweisungszeile auftritt.
Ich habe eher den Eindruck, dass beim Starten der Formularansicht die Tabelle schreibgeschützt geöffnet wird. Das sieht man auch daran, dass zuerst das Formular angezeigt wird und dann erst die LOAD bzw. OPEN - Methoden in Aktion treten.
Ich habe bis jetzt noch nicht herausgefunden, welche Methode die Formularanzeige bewirkt und die Tabelle läd und anzeigt. Da(!) scheint mir, liegt eine Überschneidung. Da muß dieser Schreibschutz entstehen!
Ich habe eher den Eindruck, dass beim Starten der Formularansicht die Tabelle schreibgeschützt geöffnet wird. Das sieht man auch daran, dass zuerst das Formular angezeigt wird und dann erst die LOAD bzw. OPEN - Methoden in Aktion treten.
Ich habe bis jetzt noch nicht herausgefunden, welche Methode die Formularanzeige bewirkt und die Tabelle läd und anzeigt. Da(!) scheint mir, liegt eine Überschneidung. Da muß dieser Schreibschutz entstehen!
Antwort 10 von testfix4711
Hm,
rein grundsätzlich müsste der Code funzen, ich nutze das in ähnlichen Situationen bis dato immer ohne Probleme.
Trotzdem noch eine Frage: Du hast bei der Open-Methode hinter dem Connection-Objekt ein ´-Zeichen, ist das ein Tippfehler ?
Nach dem RS.CLOSE solltest Du außerdem noch ein
SET RS=NOTHING einbauen, damit das Ding aus dem Speicher entfernt wird.
Prüfe doch noch mal die Formulareigenschaften, nicht das da Bearbeiten abgeschaltet ist...
Gruß
TESTFIX4711
rein grundsätzlich müsste der Code funzen, ich nutze das in ähnlichen Situationen bis dato immer ohne Probleme.
Trotzdem noch eine Frage: Du hast bei der Open-Methode hinter dem Connection-Objekt ein ´-Zeichen, ist das ein Tippfehler ?
Nach dem RS.CLOSE solltest Du außerdem noch ein
SET RS=NOTHING einbauen, damit das Ding aus dem Speicher entfernt wird.
Prüfe doch noch mal die Formulareigenschaften, nicht das da Bearbeiten abgeschaltet ist...
Gruß
TESTFIX4711
Antwort 11 von moberny
Hi, testfix4711,
vielen Dank für die Hinweise.
Aber wo, zum Teufel, finde ich die Formulareigenschaft ´BEARBEITEN´???
mfg
moberny
vielen Dank für die Hinweise.
Aber wo, zum Teufel, finde ich die Formulareigenschaft ´BEARBEITEN´???
mfg
moberny