[Access] update wordt niet direct doorgevoerd?

[Maasluip]

Ik doe in Access (2000) in VBA een update op een tabel en in een functie direct daarna selecteer ik op die tabel. Tot mijn grote verbazing zijn de veranderingen die ik in de update heb doorgevoerd nog niet aanwezig als ik direct selecteer, maar duurt het even voordat ik ze zie. Dat is natuurlijk erg onhandig, en ik kan me niet indenken dat dat ook maar enigszins normaal is.
In Oracle kun je een commit geven, maar is zoiets ook in Access voorhanden?

Ter info: mijn code, eerst de update

Visual Basic:

    Set cn = New ADODB.Connection
    cn.ConnectionString = CurrentProject.Connection
    cn.Open
    
    'remove NP/ from BCR table
    Set rs = New ADODB.Recordset       'source dataset
    sQuery = "SELECT * FROM [Excel-BCR]"
    rs.Open sQuery, cn, adOpenForwardOnly, adLockPessimistic, adCmdText
    
    Do Until rs.EOF
        Debug.Print rs.AbsolutePosition; rs.Fields(0)
        
        bUpdate = False
        If InStr(rs.Fields(0), "/") Then
            rs.Fields(0) = GetLastWord(rs.Fields(0), "/")
            bUpdate = True
        End If

        If bUpdate Then rs.Update
        rs.MoveNext
    Loop
    rs.Close

en de select code:

Visual Basic:

    
    DoCmd.RunSQL "INSERT INTO [Reporting Output] ( PLANT, SE, [SE NAME], [BCR NEW] ) SELECT F1, F2, F3, F19 FROM [Excel-BCR] GROUP BY F1, F2, F3, F19"

Wat in de upate query gebeurd is dat het PLANT veld dat er uit ziet als "NP/0000" wordt geupdate naar "0000" (dat doet de functie "GetLastWord").
In de tweede query (insert query) selecteer ik o.a. PLANT, en daar staat nog altijd "NP/0000".

Als ik snel genoeg ben en de tabel open dan staat daar ook nog altijd "NP/0000", maar als ik even wacht (een seconde of zo) dan veranderd dat in "0000".
Ik vind het een erg slechte oplossing om bijvoorbeeld een Sleep(1000) er tussen te zetten, alleen al omdat ik niet zeker weet dat na een seconde al de update is doorgevoerd.

Hoe kan ik deze update forceren? Werk ik soms niet goed met recordsets?

[RaZ]

Tis een tijdje geleden dat ik met access heb zitten stoeien.

Ik zie een rs.Update, maar waar zit je rs.Edit. Ik kan me herinneren dat je eerst een rs.Edit moet doen eer je een een waarde er in kan zetten.

Visual Basic:

    Set cn = New ADODB.Connection
    cn.ConnectionString = CurrentProject.Connection
    cn.Open
    
    'remove NP/ from BCR table
    Set rs = New ADODB.Recordset       'source dataset
    sQuery = "SELECT * FROM [Excel-BCR]"
    rs.Open sQuery, cn, adOpenForwardOnly, adLockPessimistic, adCmdText
    
    Do Until rs.EOF
        Debug.Print rs.AbsolutePosition; rs.Fields(0)
        
        bUpdate = False
        If InStr(rs.Fields(0), "/") Then
            rs.Edit
            rs.Fields(0) = GetLastWord(rs.Fields(0), "/")
            bUpdate = True
        End If

        If bUpdate Then rs.Update
        rs.MoveNext
    Loop
    rs.Close

Probeer dat eens.

[ Voor 63% gewijzigd door RaZ op 11-08-2006 14:36 ]

[Maasluip]

RaZ schreef op vrijdag 11 augustus 2006 @ 14:34:
Tis een tijdje geleden dat ik met access heb zitten stoeien.

Ik zie een rs.Update, maar waar zit je rs.Edit. Ik kan me herinneren dat je eerst een rs.Edit moet doen eer je een een waarde er in kan zetten.

Nee. Edit is geen method van een recordset object.

[TXC]

Probeer anders in plaats van docmd.runsql eens te updaten met db.execute. Bijkomend voordeel is dat je je affected rows kan checken om te zien om je update wel is doorgevoerd (met db.rowsaffected).

Visual Basic:

Dim db As Database

Set db = CurrentDb
db.Execute ("insert into test VALUES ('data1','data2')")

If db.RecordsAffected = 0 Then
  MsgBox "Kon de tabel niet updaten", vbExclamation
End If

[ Voor 35% gewijzigd door TXC op 11-08-2006 15:05 ]

[Pannenkoekkie]

ben niet zeker van mijn zaak (niet getest), nadat je je wijzigingen hebt gemaaakt, en voor je je filter gaat instellen:

code:

rs.Requery

Is een nadeel van Access imo

[ Voor 51% gewijzigd door Pannenkoekkie op 11-08-2006 14:59 ]

[Maasluip]

De rs.Requery werkt niet, dan krijg ik nog altijd mijn ongewijzigde data.
De db.Execute werkt wel (in mijn code dus cn.Execute). Het was even puzzelen, ik heb dat nog nooit gebruikt, maar nu werkt het perfect.

Het effect treedt verder nog altijd op. Als ik mijn hele data-gathering doe en ik open de outputtabel direkt daarna is die tabel leeg. Daarvan schrok ik even, maar dat is dus precies dat effect dat Access niet direkt update. Na een seconde of zo is de data er wel.

* Maasluip heeft een hekel aan Access.

[TXC]

Maasluip schreef op vrijdag 11 augustus 2006 @ 15:18:
De rs.Requery werkt niet, dan krijg ik nog altijd mijn ongewijzigde data.
De db.Execute werkt wel (in mijn code dus cn.Execute). Het was even puzzelen, ik heb dat nog nooit gebruikt, maar nu werkt het perfect.

Het effect treedt verder nog altijd op. Als ik mijn hele data-gathering doe en ik open de outputtabel direkt daarna is die tabel leeg. Daarvan schrok ik even, maar dat is dus precies dat effect dat Access niet direkt update. Na een seconde of zo is de data er wel.

* Maasluip heeft een hekel aan Access.

Ik heb al aardig wat Access projectjes achter de rug maar ik heb die problemen nog nooit gehad. Wat bedoel je eigenlijk met data-gathering (waar je zegt dat het probleem zich nog wel voordoet)?

[Lustucru]

je loopt tegen de gevolgen van performance optimalisatie van de jetengine in combinatie met caching. Je code opent een aparte ADO sessie, doet daat een en ander in en via een ander kanaal (het docmd) object vraag je gegevens op. Het docmd object weet echter niet dat er records gewijzigd zijn en retourneert nog de oude gegevens.

DAO kon direct de workspace aanspreken en die ondersteunde transacties met commit en rollback, maar dat had je in dit geval ook niets geholpen. Het enige wat helpt zijn de optieinstellingen mbt refresh intervals, waar nodig de cache flushen/records geforceerd vernieuwen en zorgen dat je code via één toegangsobject loopt.

heb hier geen access oid bij de hand, dus dat welke dat zijn moet je even zelf zoeken. Ik heb nog ergens een artikel liggen over jet en caching, maar dat wordt zoeken.

[Maasluip]

TXC schreef op vrijdag 11 augustus 2006 @ 18:31:
[...]

Wat bedoel je eigenlijk met data-gathering (waar je zegt dat het probleem zich nog wel voordoet)?

Het projectje wat ik nu aan het ontwikkelen ben moet data uit een paar Excel sheets halen, die data een beetje verfraaien en consolideren en daarna in een mooi tabelletje weer in een Excel sheet uitspugen.

Het probleem deed zich voor tussen het verfraaien en consolideren.
Wat er nu nog altijd gebeurd is dat als ik de data uit de Excel files haal, opschoon, consolideer en in de Access output tabel zet, en die open direkt nadat de voorgaande stapjes zijn gedaan (in VBA), dan is de tabel leeg. Open ik de tabel echter pas na een seconde of 2, dan is de tabel gevuld.

Bij mij heet dat "weird shit", en dat zijn precies de oorzaken waarom ik niet zo van Access hou.
De enige keer dat me zoiets in Oracle gebeurd is is toen ik delete * onderbrak en direkt een rollback deed (voor de zekerheid), maar dat was op een tabel met een paar miljoen records. Okee, dan kun je langzaam reageren (maar het zweer brak me uit). Maar dat verwacht je niet als je 2 records in een tabel zet.

[ Voor 3% gewijzigd door Maasluip op 11-08-2006 20:57 ]

[StevenK]

Maasluip schreef op vrijdag 11 augustus 2006 @ 20:55:
Bij mij heet dat "weird shit", en dat zijn precies de oorzaken waarom ik niet zo van Access hou.

Zoals je hierboven al hebt kunnen lezen is 't niet Access, maar de Jet engine die voor die weird shit zorgt.

Maak er dan een ADP met een SQL Express van ? Dan heb je al die weird shit niet

[Maasluip]

StevenK schreef op vrijdag 11 augustus 2006 @ 20:58:
[...]

Zoals je hierboven al hebt kunnen lezen is 't niet Access, maar de Jet engine die voor die weird shit zorgt.

Tja, access maakt dwingend gebruik van de jet engine.

Maak er dan een ADP met een SQL Express van ? Dan heb je al die weird shit niet

Wat en wat? SQL Express, is dat SQL server? Ik denk dat dat een beetje overdone is voor een access databaseje met 6 tabellen en een stukje VBA code.

[TXC]

En wat Niesje hierboven zegt:

...en zorgen dat je code via één toegangsobject loopt.

Ik ken de rest van je code niet maar dat moet toch te doen zijn lijkt me?

[StevenK]

Maasluip schreef op zaterdag 12 augustus 2006 @ 14:29:
[...]
Tja, access maakt dwingend gebruik van de jet engine.

Sinds office 2000 niet meer. Bij een access project heb je keuze tussen een 'gewoon' access project en een 'Access Database Project', waarbij de backend gevormd wordt door een SQL database, in de vorm van MSDE.

[...]
Wat en wat? SQL Express, is dat SQL server?

Zie boven, de laatste versie van MSDE is http://msdn.microsoft.com/sql/express/

Ik denk dat dat een beetje overdone is voor een access databaseje met 6 tabellen en een stukje VBA code.

Persoonlijk doe ik niets meer met een .mdb en alles met een adp.

[Lustucru]

Het is niet vreemd Access is een filebased desktop-database, en geen multi-user client/server ding. Het zou raar zijn om te denken dat iedere wijziging direct weggeschreven wordt en het hele bestand opnieuw ingelezen, voor alle verbindingen die met het bestand worden gelegd.

Daarom is het niveau van caching ook instelbaar, afhankelijk of het accent ligt op performance of op direct wegschrijven van data.

nofi, maar dat je dit gedrag weird shit vindt heeft meer zijn oorzaak in onbegrip van het concept (filebased) database dan dat het werkelijk vreemd gedrag ís