"Richard" wrote ...
> How are you displaying the data? If you use something like the
> MSFlexGrid control, it has a built in sort function.
> Otherwise, re-querying is usually the best way. It is the most
> flexible approach, and in this case, it should be pretty fast.
The data is being submitted to a COM module which plots coordinates on a
map. I must be able to access the re-queried data through several DO loops.
Basically, the user selects criteria which defines the sets of coordinates
he wants to see, and the coordinates are submitted to the COM module as
argument pairs. The original resultset returned by the stored procedure is
simply all the coordinates pertaining to that particular map, which is the
starting point. In other words, all coordinates are plotted at first, then
some are dropped, then added again, then others dropped, etc.
My concern is that while the original set of data the user selects remains
constant for a longer range of time, he may be creating a fairly large
number of subsets, and allowing for the possibility that several hundred
users are all doing the same thing simultaneously, I think it makes sense to
stay with data already in the Web server's memory, but I'm just guessing
It just occurred to me as I'm writing this that I could optimize the
resultset from the stored procedure. Right now, I'm just querying all the
possible rows I need, but I could pre-sort and order the data in advance,
which might make things faster when being handled by the recordset sort and
filter properties mentioned previously.
> I am not currently using SQL server so I cannot check this out myself
> - Can you construct a SQL statement using the stored procedure name as
> a table name? ie
> "SELECT * FROM myStoredProcedure WHERE Value > 10000" & _
> " ORDER BY State, InvoiceDate DESC"
> Create the WHERE and ORDER by clauses in your code. If this works,
> then t is the way I would probably do it.
What an interesting idea! I certainly will try it.
> Databases love Queries. Although recordsets have a limited Sort and
> Filter ability (if the provider, and cursor allows it), it often is
> faster to requery.
I may copy this message over to a SQL Server newsgroup and see what they
have to say about it.