How do I trap ADO Recordset events in an ASP script (W2K/IIS5)?

[Vince C.]

Hi.

I'd like to trap ADO Recordset object events in my ASP script (either VBS or JS,
no preference). I've tried (in VBS) writing a Sub rs_RecordChangeComplete(
adReason, cRecords, pError, adStatus, pRecordset ) - rs being a server-side
ADODB.Recordset object - but it doesn't get called whenever rs is moved (I
browse it in a loop).

Is there a way to catch those events from ASP?

Thanks for any hint/suggestion.

Vince C.

 

[Bob Barrows]

Hi.

I'd like to trap ADO Recordset object events in my ASP script (either
VBS or JS, no preference). I've tried (in VBS) writing a Sub
rs_RecordChangeComplete( adReason, cRecords, pError, adStatus,
pRecordset ) - rs being a server-side ADODB.Recordset object - but it
doesn't get called whenever rs is moved (I browse it in a loop).

Is there a way to catch those events from ASP?

Thanks for any hint/suggestion.

Vince C.

No. There is no way to do this in server-side ASP code.

On client-side, if you use data binding, you will have some builtin events
to use. Please follow up in a client-side code newsgroup (m.p.scripting.* or
one of the groups with dhtml in its name.)

Bob Barrows

 

[Vince C.]

"Bob Barrows" <[email protected]> a écrit dans le message de
[...]

No. There is no way to do this in server-side ASP code.

On client-side, if you use data binding, you will have some builtin events
to use. Please follow up in a client-side code newsgroup (m.p.scripting.* or
one of the groups with dhtml in its name.)

Thanks, Bob.

I knew I could do this on the client side. Too bad it can't be done sever-side.
Do you know why it is not supported on server side? Is this a security issue or
something else? It's even more sad because both IIS and IE share the same script
engine(s).

Vince C.

 

[Chris Barber]

Server side is stateless execution so the ASP page won't be there to be able
to respond to the event. If the even t never occurred then the page would
never complete.
You can achieve something similar with a polling technique - call the ASP
page repeatedly (or use XMLHTTP from the client side) to see if the event
has occurred and then handle it from there.
Depends on what event and how you want to 'handle it'.

Chris.

"Bob Barrows" <[email protected]> a écrit dans le message de
[...]

No. There is no way to do this in server-side ASP code.

On client-side, if you use data binding, you will have some builtin events
to use. Please follow up in a client-side code newsgroup (m.p.scripting.* or
one of the groups with dhtml in its name.)

Thanks, Bob.

I knew I could do this on the client side. Too bad it can't be done
sever-side.
Do you know why it is not supported on server side? Is this a security issue
or
something else? It's even more sad because both IIS and IE share the same
script
engine(s).

Vince C.

 

[Bob Barrows]

"Bob Barrows" <[email protected]> a écrit dans le message de
[...]

No. There is no way to do this in server-side ASP code.

On client-side, if you use data binding, you will have some builtin
events
to use. Please follow up in a client-side code newsgroup
(m.p.scripting.* or one of the groups with dhtml in its name.)

Thanks, Bob.

I knew I could do this on the client side. Too bad it can't be done
sever-side. Do you know why it is not supported on server side? Is
this a security issue or something else? It's even more sad because
both IIS and IE share the same script engine(s).

Vince C.

It's a limitation of the scripting engine: an object cannot be declared
WithEvents because script variables are variants. In order for a variable to
be defined with events, it has to be defined with a specific object type
when it is declared, in order for the event model to be set up (different
object types have different events, right?). You cannot declare a variant
with events, because the engine has no idea which events might apply.

With client-side code, you have the DOM to work with. The DOM is totally
separate from the script engines.

Anyways, events are intended to be user-driven, not code-driven. It is
assumed that the programmer can write code to call when his code does
something that needs a response.

Sorry,
Bob Barrows

 

[Vince C.]

"Bob Barrows" <[email protected]> a écrit dans le message de
[...]

It's a limitation of the scripting engine: an object cannot be declared
WithEvents because script variables are variants. In order for a variable to
be defined with events, it has to be defined with a specific object type
when it is declared, in order for the event model to be set up (different
object types have different events, right?). You cannot declare a variant
with events, because the engine has no idea which events might apply.

With client-side code, you have the DOM to work with. The DOM is totally
separate from the script engines.

Ok, I see now. So the DOM inside MSIE, for instance, is the one that
automatically binds to events on objects I manipulate in a client script.

Anyways, events are intended to be user-driven, not code-driven. It is
assumed that the programmer can write code to call when his code does
something that needs a response.

That's also right. But my point was the following: if you create a class that
has to manipulate an object, which has events, you should not need to define
events of the same kind on your class. Since ADO Recordset can trigger events
when recordset pointer moves I was hoping I could create a class (actually a
server-side script component) that would not need to care about recordset
events. Now I see it has to.

The events I wanted to trap are related to recordsets, not to my class. This
leads to a syntactical contradiction. But I admit your point in that I should
code it different.

Thanks for your help.

Vince C.