[asp] MoveNext doet het niet met CursorLocation=adUseClien

[Verwijderd]

We gebruiken ASP met javascript en COM-objecten. We lopen nu tegen iets geks op, in combinatie met ADO (v2.6).

JavaScript:

var o=new ActiveXObject('project.class');
//Deze method vult de objRs (type ADODB.Recordset) property. 
//Belangrijkste properties:
//CursorLocation = adUseClient; adOpenStatic en adLockReadOnly
o.getList(); 
while(!o.objRs.EOF)
{
  Response.Write(o.objRs(0)+',');
  o.objRs.MoveNext();
}

De code hierboven komt in een oneindige lus terecht. Er wordt steeds hetzelfde record geprint

De volgende code doet het wel:

JavaScript:

var o=new ActiveXObject('project.class');
//Deze method vult de objRs (type ADODB.Recordset) property. 
//Belangrijkste properties:
//CursorLocation = adUseClient; adOpenStatic en adLockReadOnly
o.getList();
var rs=o.objRs;
while(!rs.EOF)
{
  Response.Write(rs(0)+',');
  rs.MoveNext();
}

Wel, dat is mooi zou je zeggen, maar waarom
/me En: de originele code doet het ook als je een serverside cursor gebruikt.

Prik ons lek , we snappen het niet meer

[Phenomenon]

Moet het niet zijn while not (!rs.eof) ????

Maar ik ben dan wel een leek in Java, maar kijkt zo raar voor mij.

[maikel]

Supervisor schreef op 29 oktober 2002 @ 19:08:
Moet het niet zijn while not (!rs.eof) ????

Maar ik ben dan wel een leek in Java, maar kijkt zo raar voor mij.

Er staat ook een 'not'. Dat uitroepteken betekent 'not'.

[Verwijderd]

Het lijkt dus wel als of je (in het eerste geval) bij elke keer dat je dereferenced vanuit o een nieuwe kloon van objRs krijgt. Hopelijk heeft het niet te maken met de "speciale" manier waarop IIS/MTS omgaat met COM-objecten... (Ik herinner me de nodige verzuchtingen van ene Daniel over dit onderwerp, jij ook? ;-). Ik zou me kunnen voorstellen dat een client side cursor het recordset object ergens anders heeft "draaien" dan een server side cursor of zo iets vaags.

[Verwijderd]

idd, wij (JanT en ik) dachten idd aan dat klonen van objRs (ipv nieuwe reference). Nu ik er verder over nadenk, zou dat de oplossing met de server-side cursor ook verklaren.

Maw: het kiezen van een server-side cursor is niet tof, omdat er bij elke verwijzing kennelijk een kloon maakt wordt, en dat is niet super qua geheugen enzo.

Maar het alternatief is ook minder tof, want dan moeten we alle code bij langs

WIE HEEFT COM OOIT BEDACHT !!
* doekman wil geen kwaad woord over javascript horen

Hopelijk heeft het niet te maken met de "speciale" manier waarop IIS/MTS omgaat met COM-objecten...

Ik denk het niet. Ik ben bang dat dit het gevolg is van de brakke binding tussen javascript en COM. Ik ga scenario morgen ook maar 's in VBScript proberen, en ben bang dat het dan wel goed gaat...

edit:
Ik bedacht me net, zou het gebruiken van Server.CreateObject ipv new ActiveXObject nog uitmaken?

[ Voor 0% gewijzigd door Verwijderd op 29-10-2002 22:51 . Reden: xtra ideetje ]

[Verwijderd]

Nah, don't get mad... Get even! :-P

[ Voor 0% gewijzigd door Verwijderd op 29-10-2002 23:29 . Reden: Smiley vergeten ]

[Verwijderd]

Nog even een toevoeging: het beschreven gedrag doet zich alleen voor in debugging modus.

[maikel]

Debugging mode in javascript ??

[_Thanatos_]

Uhm, een COM object maak je toch altijd aan met Server.CreateObject(..);

[Verwijderd]

maikel schreef op 31 oktober 2002 @ 20:17:
Debugging mode in javascript ??

Ik bedoelde het debuggen van het COM-object. Overigens schijn je javascript ook server-side te kunnen debuggen. Ik heb er nog nooit echt veel tijd voor over gehad.

_Thanatos_ schreef op 01 november 2002 @ 02:03:
Uhm, een COM object maak je toch altijd aan met Server.CreateObject(..);

Niet altijd. new ActiveXObject kan dus ook, maar die laatste werkt weer niet samen met COM.