[ADO] Probleem met uitlezen recordset na toevoegen record

[Verwijderd]

Hello;
In een ASP script wordt er een record toegevoegd aan de database.
Dit record moet vervolgens in een volgende recordset worden uitgelezen.

Omdat de commando's achter elkaar worden gegeven heeft de database blijkbaar nog niet de tijd gehad om zichzelf te refreshen. Dit resulteert in een output zonder het zojuist toegevoegde record.

Weet iemand hoe je een ADO connectie kunt refreshen zodat de records in een vervolgcommando wel gewoon gevonden worden ?

alvast bedankt !

[Verwijderd]

ik heb geen verstand van asp, maar in visual basic zorg je dat het ado component gere-queryd wordt. Dus bijvoorbeeld door de slq-query select * from tabel op de recordsource van het adocomponent opnieuw uit te voeren. Ik weet niet hoe het werkt bij asp, maar misschien heb je hier iets aan.

[farlane]

De update / insert bij een ADO component kan nog gebufferd zijn, maar volgens mij wordt een insert / update query meteen uitgevoerd.

[Verwijderd]

je hebt wel objRecordset.Update uitgevoerd?

[Verwijderd]

Je kan toch ook na het toevoegen van de record de pag opnieuw openen is gelijk aan een refresh.

[Verwijderd]

na een [rs].addnew moet je inderdaad altijd een [rs].update draaien.

[farlane]

Verwijderd schreef op 09 September 2003 @ 16:35:
na een [rs].addnew moet je inderdaad altijd een [rs].update draaien.

Dan nog kan het flushen naar de db gecached zijn als je meteen een select doet !

[faabman]

Misschien is het handig als je even laat zien wat je doet, op deze manier kunnen wij namelijk niet bepalen welke query je gebruikt om je nieuwe record terug te geven...

[Verwijderd]

Okay...
de volgende actie voer ik uit:

code:

conn.execute("INSERT INTO tblGROEP(naam) VALUES('TEST')")
myNewID = conn.execute("SELECT @@IDENDITY").fields(0)

conn.execute("INSERT INTO tblGROEPGEBRUIKER(userid,groepid) VALUES(" & userID & "," & myNewID & ")"

Omdat de code wordt uitgevoerd op een Access Database (en er onderliggende relaties bestaan), geeft IIS een melding als:

- Je kunt geen records toevoegen omdat een record in een andere recordset vereist is..

Kortom; het record in tblGroep is nog niet goed verwerkt en zodoende kan de 2e query niet goed uitgevoerd worden.

Zo voldoende informatie ?

P.S. Aangezien ik niet met een recordset werk heeft .update of .requery weinig zin !

[farlane]

Hmm, en twee insert met een eigen ID ( zonder die maffe @@IDENTITY ) gaat wel goed?

[Verwijderd]

code:

'--- Build SQL string
strSQL = "SET NOCOUNT ON " & _
    "INSERT INTO [" & m_strArticleDBTable & "] (" & _
    "[art_Title], " & _
    "[art_Description]) " & _
    "VALUES (" & _
    "'" & ValidSQLString(m_strArticleTitle) & "', " & _
    "'" & ValidSQLString(m_strArticleDescription) & "');" & _
    "SELECT [art_ID] = @@IDENTITY; " & _
    "SET NOCOUNT OFF"
        
'--- Create an instance of the ADODB.RecordSet and retrieve records from database
Set rsArticle = m_cnCategory.Execute( strSQL )
        
'--- Store newly generated id in member variable
m_intArticleID = rsArticle.Fields("art_ID").Value

dit werkt prima bij mij

[Greyfox]

Hou er wel rekening mee dat @@Identity veranderd kan zijn als je dat niet in 1 transactie doet.
Als er tussen jouw 'insert' en de 'select' een andere insert plaatsvind, krijg je dat ID.

[Verwijderd]

precies.. en daarom kun je ook beter al je sql vanuit een SP doen en niet rechtstreeks vanuit de code ...

Ik doe tegenwoordig alle's via een SP.. Werkt ook nog eens stukke sneller.

[gorgi_19]

Verwijderd schreef op 10 september 2003 @ 09:18:
precies.. en daarom kun je ook beter al je sql vanuit een SP doen en niet rechtstreeks vanuit de code ...

Ik doe tegenwoordig alle's via een SP.. Werkt ook nog eens stukke sneller.

Da's niet per definitie waar..

Zie ook: http://weblogs.asp.net/fbouma/posts/7008.aspx

[Verwijderd]

gorgi_19 schreef op 10 September 2003 @ 09:47:
[...]

Da's niet per definitie waar..

Zie ook: http://weblogs.asp.net/fbouma/posts/7008.aspx

laat ook maar hier stond wat maar dat heb ik maar weg gehaald

[ Voor 20% gewijzigd door Verwijderd op 10-09-2003 10:01 ]