[Access] Probleem met wijzigen waarde van tijdelijk veld

[zwippie]

Ik voer de volgende code uit vanuit een module in Access 2000. Er worden een aantal records geselecteerd waarbij een score moet worden berekend. De berekening voor de score is te ingewikkeld om in een query te doen. (relevante code met bogus namen)

Visual Basic:

Dim dbs As DAO.Database
Dim rst As DAO.Recordset
Dim strSql as String

Set dbs = CurrentDb
strSql = "SELECT Dingetjes.*, 0 AS Score FROM Dingetjes " & _
        "WHERE (<knip>)"

Set rst = dbs.OpenRecordset(strSql, dbOpenDynaset)

' Verander de score waarden
rst.MoveFirst
Do Until rst.EOF = True
   rst.Edit
   rst.Fields("Score") = 10    ' <- Hier komt de foutmelding
   rst.Update
   rst.MoveNext
Loop

Probleem: De waarde van het tijdelijke veld Score kan niet worden aangepast. Hier krijg ik een foutmelding over.

Debuggen leert dat de eigenschap 'DataUpdatable' van dit veld onwaar is. De rest van de velden, die gewoon geselecteerd worden uit een tabel, zijn wél updatable.

Waarom kan ik het score veld niet aanpassen? Op MSDN kan ik nergens vinden dat een tijdelijk veld niet kan worden gewijzigd. Wat zie ik over het hoofd?

[CodeCaster]

Ik vind dit met http://www.google.nl/search?q=dao.recordset+read+only

Is dat wat?

[zwippie]

Lijkt er wel op, maar je eerste link gaat meer over ADO ipv DAO. Er staat wel een workaround in die gebruik maakt van DAO, maar die zet me ook nog niet op het goede spoor...

[Masch]

Is het niet gewoon een syntaxfout en moet je niet het onderstaande doen?

Visual Basic:

rst.Edit
rst!Score = 10    ' <- Hier komt de foutmelding
rst.Update 

[zwippie]

Nee, dat maakt niet uit, het wijst naar precies hetzelfde. (getest)

Wel bedankt voor het meedenken!

[Verwijderd]

als ik het goed begrijp wil je de berekende kolom Score achteraf wel permanent in de database hebben. misschien is het beter als je eerst effectief in de tabel deze kolom aanmaakt (eventueel eerst testen of de kolom al bestaat), en daarna de volledig updatable recordset bewerkt.

[zwippie]

Nee, ik wil de kolom Score niet permanent in de database hebben, het is een tijdelijk veld.

Maar aangezien ik met deze code wél de kolommen die in een tabel staan kan wijzigen, denk ik er over om van Score toch maar een (leeg) veld in de tabel van te maken.

Niet echt de mooiste oplossing, omdat Score elke keer opnieuw wordt berekend en dus eigenlijk niet hoeft op te worden geslagen, maar DAO gooit hier roet in het eten.

[Verwijderd]

moet je de edit en update niet eenmalig doen, dus buiten de loop houden.

en volgens mkij is het ook rst!score = 10

[ Voor 24% gewijzigd door Verwijderd op 04-09-2006 15:47 ]

[CodeCaster]

Wat je touwens waarschijnlijk probeert te doen is je zoekresultaten een score geven?

Je kunt dat ook doen door gewoon met code een nieuwe array te maken en die te koppelen aan je resultaten, om in die array dan de score te stoppen. Hierna kun je met bijvoorbeeld een bubble sort de resultaten sorteren.

[zwippie]

@Hans_Kazan:
rst!score is een korte notatie van rst.Fields("Score"), ze doen beide dus precies hetzelfde.
De edit en update kunnen inderdaad buiten de loop, maar dat lost het probleem niet op.

@CodeCaster:
Ja, zoiets doe ik inderdaad. In een array stoppen is wel een mogelijkheid, maar dan is het weer minder makkelijk om het resultaat in een formulier te hangen. Misschien zijn daar wel maniertjes voor, daar heb ik me nog niet in verdiept.

[Lustucru]

Je begint met een constante te definieren, en die wil je later aanpassen. Dat werkt idd niet. Wat eventueel wel voldoet voor je is de 'score' berekening in een functie opnemen en die rechtstreeks aanroepen in je sql.

code:

Function CalcScore([noodzakelijkVeld]) as long
       CalcScore=10
End Function

Select *, CalcScore([id]) as Score From Dingetjes

[zwippie]

Ja, het getal 10 toekennen was natuurlijk een voorbeeldje, maar het lijkt er inderdaad op dat een berekende kolom in de query later wordt gezien als een constante. Stom, zo had ik er gewoon nog niet over nagedacht.

Morgen ga ik hiermee verder. De berekening in de query op nemen is inderdaad de mooiste oplossing, toch maar eens kijken of dat haalbaar is.