Oscar said:
Stefan and Bob thanks for your documented example and especially that
you've got it running now.
However, where is the action that the ASP page calls the other HTML
page to open in the client browser ?
The html page controls the activity. When the .htm page is opened, it sends
a request via the rs.open statement to the asp page, which runs on the
server and returns the requested recordset. Obviously, you would use
querystring variables to pass parameters to the asp page via the url in the
Open statement to control what data is returned. In fact, using this method,
you are restricted to using the querystring, which is another reason I
prefer using the XMLHTTPRequest object, in addition to the reasons mentioned
by Mark.
Another factor to consider is passing the data back to an asp page. Using
the xmlhttprequest object makes it possible to pass the recordset back to a
server-side page.
Are there restrictions with respect to the size of the recordset when
using the resonse object?
None that I know of. When I experimented with passing recordsets to browser
clients, I made sure the recordsets were not very large (a few hundred rows
at the max). Usualy, I was passing around a disconnected recordset
containing a single row, using UpdateBatch to send changes back to the
database after the recordset had been processed by one or more pages.
Unfortunately, that application crashed and burned: it ran well in
development and testing on several machines. However, a week or so after it
went into production, we started getting calls: "createobject failed ..." on
this machine, "ADO error" on that machine ... updating/reinstalling MDAC on
those machines solved most of the problems, but there were a couple machines
which have never been able to run this app - MDAC was completely hosed on
those machines. As a result, I rewrote the app to remove any mention of ADO
in client-side code, and I have never written another app that used
client-side recordsets. Any client-side data processing is done via XML.
Bob Barrows