difficult paging problem

Results 1 to 2 of 2

Thread: difficult paging problem

  1. #1
    Join Date
    Dec 1969

    Default difficult paging problem

    Hi,<BR><BR>I am having problems paging through a recordset in the way I need to.<BR><BR>in a nutshell I first let users select a product from a list and this takes them to a details page where the products details are displayed. This page is in a frame as details are hardcoded in a word document and cannot be dynamically created from a database.<BR><BR>The frame page is therefore split in two:<BR><BR>top frame - navigation page<BR>main frame - the chosen product&#039s word document<BR><BR>in the top frame (the navigation page) I need to display the chosen product name and allow the users to page through one record at a time through the other products - using next and previous buttons.<BR><BR>When the users clicks either button this should also display in the main frame the required document. I have therefore created a document location field in the product table so this can be determined. When the users clicks next I retrieve the products document location from the recordset and pass the location through a querystring which goes to the details page and loads the correct document in the main frame. <BR><BR>The problem lies in the paging will only work if I do not filter the recordset by the product id. In order to figure out how many records are in the table and for paging to work I must do a select * from myproductable.<BR><BR>Therefore, when the users clicks the required product from the index page only the location doc is loaded in the main frame, but the navigation page in the top frame only displays the first record in the table not the chosen record.<BR><BR>any ideas how I can resolve this, this is making my brain hurt.<BR><BR>cheers<BR><BR>Mark<BR><BR>

  2. #2
    Join Date
    Dec 1969

    Default Two ways that I see...

    Two ideas:<BR><BR>(1) How many total records? If not too many, load *ALL* the records into the Nav frame and *never* do an ASP call to get the NEXT or PREVIOUS. Just "scroll" through an array of in-memory records (in JS code, of course). To "sync" with the requested document is now easy: Just search through the array for the match. Surely fast enough for up to a couple of hundred records.<BR><BR>(2) If too many for the above...<BR><BR>From the index page, you do <BR> &nbsp; &nbsp; SELECT ... WHERE productID = nnnn<BR>Note the = comparison.<BR><BR>That gets you right to the needed record, of course. You display the matching document.<BR><BR>For your NEXT button, you have it generate<BR> &nbsp; &nbsp; SELECT TOP 1 ... WHERE productID &#062; nnnn ORDER BY productID<BR><BR>See it? You get the ONE record that is the first one with a key value *greater* than the current record.<BR><BR>And for your PRIOR button, you generate<BR> &nbsp; &nbsp; SELECT TOP 1 ... WHERE productID &#060; nnnn ORDER BY productID DESC<BR><BR>Same thing, but now we use a DESCending sort to reverse the order *and* we get only records with key values less than that of the current record.<BR><BR>Naturally, as you move to a new record, you simply grab the contents of the "current" productID field to use in the comparison operation of the NEXT or PRIOR selection. By passing that ID (hidden form field?) and a "NEXT" or "PRIOR" form value to yourself, you can easily generate the proper SQL.<BR><BR>No? What do you think?<BR><BR>************<BR><BR>Personally, I favor plan 1. It puts a *lot* less load on the server and the user will seem to see instant results (except for the time to load the ".doc" file, but nobody can do anything about that). I&#039d seriously consider it up to perhaps even 300 to 500 records. Consider: Even if each record needs 100 bytes of info in the browser, that&#039s still only 50K Bytes of memory in the user&#039s machine. And even on a 56K baud connection, it only takes about 10 seconds [probably less--it will be text and be compressed by the modems] to send all that info. So first search is a bit slower but other pages are much faster.<BR><BR>Balance, balance, balance. It&#039s what programming is all about.<BR><BR><BR>

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts