>I have an ASP page that does a database query. It typically retrieves between 0 and 15 records, with 4 fixed-length fields from each record including a unique identifier, and realistically the query is constrained to not ever retrieve more records than that. Regardless of how many are actually retrieved, there is _no_ guarantee that information from all of them will actually be used somewhere on the dynamically generated page. If used, the elements of data are distributed "here and there", not in a list.
>
>My question: What is the most efficient strategy for implementing the query? For example:
>- Create an ADO recordset and persist the recordset throughout the life of the page, and look into the recordset to find the elements of data I need to use at specific points in the page.
>- Create an ADO recordset, and from it populate some global script variables (such as arrays or uniquely delimited strings) that can be used throughout the page to provide the elements of data used at specific points in the page.
>- Use an MTDLL to create VFP cursor, and persist the cursor throughout the life of the page, and do COM callbacks to fetch (from the cursor) the elements of data I need to use at specific points in the page.
>- Use an MTDLL to create VFP cursor, and from it populate some object properties (or simply pass back a constructed text blob) as uniquely delimited string(s) that can be used throughout the page to provide the elements of data used at specific points in the page.
>- I assume that the least efficient approach is to do a more specific query that retrieves only one data element in an "on demand" basis, i.e., where the query is repeated with a more granular WHERE clause every time a specific data element is needed at a specific point on the page.
>- Other?
>
>Thanks very much.

Mark,
As far as I understood I'd choose:

"the least efficient approach is to do a more specific query that retrieves only one data element in an "on demand" basis..."

Cetin