Overview: RSFast - New Features in the Works
by Charles Carroll

The following features will appear in next versions of Rsfast. We mention then now so you can see if we addressed any limit you found.

http://www.asplists.com/asplists/asprsfast.asp
is location of listserver where we discuss this library. You can get help on using Rsfast or you want to discuss these features below implementations or suggest features you would like us to add.

Template Improvements - Listboxes supporting two keys. Javascript arrays. Paged support will get default navigation bars.

Index Server Support - People can use it for site searches with this feature. 

Stored procedure parameter support - nuff said.

New Templates - checkboxes and radio-buttons.

banding - Allows grouping and formatting the groups.

Imagine a query like this =>
select * from publishers where state='ny' order by city

Albany header
... a bunch of Albany Data
Albany footer

Buffalo header
... a bunch of Bufallo Data
Buffalo footer

Chelsea header
... a bunch of Chelsey Data
Chelsea footer

In the new version you can have a special additional header/footer for each city band. Or there could be state, city and zip bands and relevant templates if a multiple order by was involved.

Cache Rule to Detect Added Records -

To make long cache durations more feasible, a new cache directive 
    .add "cachemaxid", "fieldname"
would be introduced.

For example
   .add "cachemaxid", "projectcode"
would have the following effect.

The first time the data is fetched, the highest id in the recordset would be placed in
application(cachename & "_cachemaxid")

Next time the cache was hit, it would run the query
"select ... from ... where projectcode>" & application(cachename & "_cachemaxid")

a. That would be a cheap fast query that resulted in Zero Records if there was no new data.
b. If there was new data the cache would be re-fetched

Cache Rule to Detect Modified  Records -

To make long cache durations more feasible, another new cache directive
   .add "cachedatetimefield", "fieldname"
would be introduced.

For example
   .add "cachedatetimefield", "projectupdated"
would have the following effect.

The first time the data is fetched, the highest date/time in the recordset would be placed in
application(cachename & "_cachedatetimefield")

Next time the cache was hit, it would run the query
"select ... from ... where projectupdated<" & application(cachename & "_cachedatetimefield")

a. That would be a cheap fast query that resulted in Zero Records if there was no modified data.
b. If there was new data the cache would be re-fetched

Cache Rule to Detect File Changes  -

To make long cache durations more feasible, another new cache directive will allow a cache to be dirtied whenever a file is modified.

    .add "cachefilelink", "whatever.xxx"

If whatever.xxx date/time changes, the cache will be rebuilt.

Named fields - named fields like {state}, {city} can be used in addition to {0}. Some ADO properties {fieldname}, {fieldsize}, etc would be supported.

Nth row formatting - if every other row need shading or every nth. row needs a format change this feature allows formatting changes each nth. row

Simple Row Template - A simple row_template will be provided so that for example this spec would exist:
<tr><td>{city}</td><td>{state}</td><td>{zip}</td>
as an alternative to having to specify rowheader, rowfooter, colheader, colfooter for example.

Date/Time Formatting - Date-formatting ala:
http://www.4guysfromrolla.com/webtech/022701-1.shtml and similar numeric formatting will become standard and can be applied at the format or cache level (to avoid having to re-format every time the data is fetched).

Retrieval Method and Chunking - Word is that Getrows and Getstring are quite server killers when 1,000s of rows are being fetched. Next version allows people to select method so they can request Getrows or Getstring can be used internally when expecting to deal with large data sets since I hear it beats out getstring. I suspect server config affects which is more efficient and it is not clear cut. Chunking works like:

DO UNTIL rstemp.eof
   x=rstemp.getstring(,500,...)
LOOP

DO UNTIL rstemp.eof
   x=rstemp.getrows(500)
LOOP

Get Back Raw Data - RSFastArray SUBroutine. The calling code would look like:

DIM fieldmap,mydata,totalrecs, countrec
Call RsFastArray(mydata,fieldmap,totalrecs)

FOR countrec=0 TO totalrecs
    city=mydata(fieldmap.item("city"),countrec)
    state=mydata(fieldmap.item("state"),countrec)
    zip=mydata(fieldmap.item("zip"),countrec)
   ....
NEXT

Subqueries - Triggering new queries inside the "array walk".

Banding enhancement - Adding, averaging, min/max numeric fields within each band.

Multi-column work - very similar to Asp.net repeaters.

Randomized data order  - this feature helps test out reports or plays on users tendencies to click on first records when all records are of close quality.

Misc. Optimizations - The following code tweaks are planned

• Nulls and Blanks won't be dealt with in a loop.
  I will just run a replace #c##c# => blankcharacter
  replace #c##n##c# => nullcharacter
  on the data string.
  That eliminates the IFs being run n times in the loop.
• If formatting strings are simple enough (col and row ends only, table or list templates) getstring will be done directly without all the LOOPs and parsing.
• If no fld_xxx templates are "in play" an alternate loop will be used to eliminate so many IFs.
• The concept of many app vars to support a cache will go away. Instead of caches resulting in lets say 6 variables, i.e.
  1. data
  2. fieldmap
  3. durations
  4. creation time
  5. cachemaxid
  6. cachedatetimefield
  etc.
  There are actually quite a bit of performance data in appvars that will be packed up in next version tabulating summary data (best/worst/average ms timing about every query RSFast executed).
  There will only be 4 app vars:
  data
  fieldmap
  dataextended
  dataextendedfieldmap
  and all the individual cache settings will be packed up in that two appvars and correlated with the fieldmap.

Chaz Wish List Tall Tip $5 Grande Tip $20 Venti Tip $39 Tip Jar Thanks 2004 Thanks 2005 Thanks HUGE Tip -love site