recordset update

[Eibert]

Aan de hand van een formulier wil ik een bestaand record bijwerken.
Daartoe heb ik de volgende code gebruikt:

Dim sql As String
Dim rst As Recordset
sql = "Select * FROM Persoon WHERE P_id = " & Me.Pers_id
Set rst = CurrentDb.OpenRecordset(sql)
rst.Edit
rst.Fields(1) = Me.txtNaam
rst.Update
rst.Close

Bij uitvoering krijg ik de melding

Fout 3197 tijdens uitvoering.
De microsoft Jet-database-engine heeft het proces gestopt omdat u en een andere gebruiker dezelfde gegevens proberen te wijzigen.

Ik ben de enige gebruiker.
De vorige keren is de recordset keurig gesloten.
Er wordt niet tussentijds uit een lus gespronegn tijdens een bewerking.
Wat kan er wel aan de hand zijn?

 

[Greenery80]

Nothing

Als het de vorige keren heeft gewerkt komt het vast doordat rst nog is gevuld.
rst = Nothing

Probeer dit eens:

Dim sql As String
Dim rst As Recordset

sql = "Select * FROM Persoon WHERE P_id = " & Me.Pers_id
Set rst = CurrentDb.OpenRecordset(sql)
rst.Edit
rst.Fields(1) = Me.txtNaam
rst.Update
rst.Close
[COLOR="Red"]Set rst = Nothing[/COLOR]

 

[OctaFish]

Dat idee had ik ook; je kunt zelfs de regel rst=Nothing ook aan het begin zetten, zodat je de procedure in ieder geval kunt starten.
Ander alternatief: maak een nieuwe recordset aan met een andere naam, en kijk dan of het wel lukt.

Michel

 

[Eibert]

Helaas, deze oplossingen werken niet.
Ik heb alle keren dat ik een recordset aanriep de regel

set rstxx = Nothing

toegevoegd. Dat lijkt me op zich al een verbetering, om het geheel robuuster te maken.
De naam had ik al eerder gewijzigd. Helpt ook niet.
De aanroep gebeurt ook vanuit een functie, je zou verwachten dat buiten de functie alle waarden vervallen.

Daarnaast merk ik, dat als ik de toekenningsregel uitschakel

'rst.Fields(1)=Me.txtNaam

het geheel geen foutmelding geeft. Maar ja, dan verandert er ook niets.
Bij het vervangen van Me.txtNaam door een string weigert het geheel ook te werken.

Zijn er nog andere mogelijkheden?

 

[OctaFish]

Als iets werkt, en op een bepaald moment niet, dan moet er over het algemeen iets zijn veranderd, in tabel of database. Enig idee of dat zo is? Blijft er geen ldb bestandje achter als je de database sluit?

Michel

 

[Greenery80]

Hoi Eibert,

maar even wat vragen om een beeld te krijgen van het probleem:

allereerst welke office versie gebruik je?
Als tweede zoals Octafish stelt: blijft er een ldb bestand staan na afsluiten van de db?
Comprimeren en herstellen al geprobeerd?
Is er een probleem opgetreden bij het afsluiten, verlies van netwerkverbinding of schrijfprobleem naar je schijf?
Gebeurd er iets met de data die je probeert te updaten? Bijvoorbeeld #Verwijderd

 

[Eibert]

Ik kan geen .ldb ontdekken.
Comprimeren helpt niet.
het probleem doet zich trouwens voor in het origineel en in de kopie, waar ik naat hartelust in kan knoeien.
Ik werk met Office 2003, XP sp3.

Het is voor mij een raadsel, omdat de constructie elders met een andere tabel wel werkt.

 

[OctaFish]

Het ldb bestand wordt aangemaakt op het moment dat je de database opent. Als alles netjes wordt afgesloten, wordt het verwijderd door Access. Bij problemen zie je dan ook vaak dat het ldb bestand blijft staan in de map van de database. Weggooien kan dan problemen verhelpen.
Maar ik begrijp, dat je geen achtergebleven ldb hebt?
Ook heb je al een kopie gemaakt van de database / tabel? En in beide zit hetzelfde probleem? En de procedure doet het wel op een andere tabel?
Dan begin ik toch te denken, dat er iets mis is met ofwel de tabel waarin je werkt, omdat de kopie tabel hetzelfde probleem heeft, ofwel met een specifiek record dat je probeert bij te werken.
Heb je al geprobeerd om de routine op een andere tabel in dezelfde database te draaien?
Wat je ook nog kan proberen, is de tabel waar het probleem inzit te dupliceren met een Tabelmaak query. En dan weer kijken wat er gebeurt als je de routine er op los laat.
Kun je overigens de waarde van het veld dat je probeert bij te werken wel uitlezen in een messagebox?

Michel

 

[Greenery80]

ah gelukkig, dat dezelfde constructie wel werkt in een andere tabel.
Dit betekend in ieder geval dat je db of Microsoft Jet db engine niet corrupt is!

Maar het zou eventueel nog wel kunnen dat de tabel of het formulier corrupt is.
Kortom mijn advies is ook een nieuwe tabel en nieuw formulier.

 

[Eibert]

Nee, geen .ldb.
Nu ik een kopie van de tabel heb gemaakt (simpelweg de structuur plakken, en daarna de data plakken) werkt het wel op de kopie. Geen wijziging van structuur, en van gegevens dus.

De originele tabel is een gekoppelde tabel. Via MySQL-connector 5.1.5. is er een koppeling met MySQL.
Maar daar werk ik meer mee, en dat geeft tot nu toe nooit problemen.
Dus nu uitpuzzelen hoe ik de gekoppelde tabel hetzelfde laat doen als de 'zuivere' Access tabel.
Dat wordt morgen, vrees ik.
Heb je nog suggesties of een denkrichting?

 

[Greenery80]

ik vond een vergelijkbaar probleem:

.executes ipv .update .edit

De vragensteller stelt in principe dat (misschien) het volgende werkt voor jou:

strSQL = "UPDATE Persoon SET veld1=" & Me.txtNaam & " WHERE P_id = " & Me.Pers_id & ";"
CurrentDb.Execute strSQL

veld1 nog wel even veranderen!

Je kunt ook Docmd.RunSQL gebruiken (access interface).

 

[Eibert]

Ook deze suggesties hielpen niet.
Ik heb het hele verhaal opnieuw opgebouwd, te beginnen bij de update van een enkele tabel.
het probleem bleek toch te zitten in de gekoppelde tabel.
De oplossing: een onafhankelijk formulier erbij maken, daar eerst (automatisch) naar toe springen, met overheveling van gegevens, de veranderingen doorvoeren, en dan weer terug naar het oorspronkelijke formulier.
Het lijkt omslachtig, maar het werkt wel.

Bedankt voor jullie inzet.

 

[OctaFish]

Ik krijg een akelig vermoeden dat ik nu weet waardoor je probleem wordt veroorzaakt....
Kijk eens in de gekoppelde tabel, er vanuit gaande dat het een SQL Server database is waaruit je koppelt, en controleer eens of er in die tabel een veld zit met de eigenschap Bit.
Zo ja, dan praten we verder...

Michel