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

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
Wed Nov 19 10:59:22 CST 2003

Vince C. wrote:
> 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

--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.

Vince
Thu Nov 20 03:51:04 CST 2003

"Bob Barrows" <reb01501@NOyahoo.SPAMcom> a écrit dans le message de
news:OnUU85rrDHA.2364@TK2MSFTNGP09.phx.gbl...
[...]
> 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
Thu Nov 20 03:59:20 CST 2003

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.

"Vince C." <none@hotmail.com> wrote in message
news:OIRxRv0rDHA.3140@TK2MSFTNGP11.phx.gbl...
"Bob Barrows" <reb01501@NOyahoo.SPAMcom> a écrit dans le message de
news:OnUU85rrDHA.2364@TK2MSFTNGP09.phx.gbl...
[...]
> 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
Thu Nov 20 05:25:19 CST 2003

Vince C. wrote:
> "Bob Barrows" <reb01501@NOyahoo.SPAMcom> a écrit dans le message de
> news:OnUU85rrDHA.2364@TK2MSFTNGP09.phx.gbl...
> [...]
>> 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

--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"

Vince
Fri Nov 21 07:57:23 CST 2003

"Bob Barrows" <reb01501@NOyahoo.SPAMcom> a écrit dans le message de
news:eJ3F$k1rDHA.3536@tk2msftngp13.phx.gbl...
[...]
> 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.