There is really no point in wrapping the ADO COM with another COM, and you
will experience a slowdow as David suggests below. Paging can be done
easily with a client sided cursor. http://www.4guysfromrolla.com has a good
example of this.
In the past I have only found it necessary to encapsulated the ADO within a
custom COM when there is a security issue involved.
Unless your plan on using the COM stored in the session (*puke*), you will
gain no advantage of using it.
(im sure i do not have to go over the reason for the *puke* with relation to
the session object).
From: David Sussman [mailto:davids@i...]
Sent: Monday, March 20, 2000 5:12 AM
To: Code Clinic
Subject: [proasp_codeclinic] Re: How Do I Page ADO Data from Com
As a simple solution, why not just replace the construction of the
original recordset with a componet call that returns the recordset? This
should leave the paging code in your asp page intact.
If the requirement is to move the paging logic to a component, then you
can construct a separate recordset in the component and just copy over
those rows in the current page to the new recordset. This, of course,
introduces a slight slowdown, so you might not be so happy with it. The
nature of SQL means that a paging solution will always require some form
"Andy" <andrews@a...> wrote in message
> Currently I have asp paging data directly from Oracle with no problems
> using the ADO recordset to control the paging.
> We now need to seperate all sql logic into our application server.
> This leaves me with the problem of how to page data from a COM
> Has anyone any experience with this ? or can you point me in the right
> direction for some reference material.
> Any help would be appreciated
> You are currently subscribed to proasp_codeclinic.
You are currently subscribed to proasp_codeclinic.