>OK. We all know and have read and seen for ourselves that in a client/server environment the "old" navigation, i.e. VCR back/forward/top/bottom, is not practical.
>
>But let's leap over that for a second, and assume that we have a project where that type of navigation is an absolute requirement. (Do not waste your time responding that I should convince them otherwise.)
>
>The question is the best approach to bringing down the data for the main navigation screen. Lert's assume we have SQL Server like this:
>
>tableMain1 - - - |
>tableMain2 - - - -| -- these 3 tables combine to form the view that we must navigate thru. initially 10,000 records but could grow to a million rows
>tableMain3 - - - - -|
>
>Then that view has a one - > > and one -- > relationship with 7 tables. However each of those 7 tables need to potentially display on the master navigation screen, with 0-50 child records in each of the 7 tables
>
>What do the wise people here think would be the best approach?

I don't see the VCR navigation as impractical at all. Paging is a definitely good approach. In fact, that's what FoxPro's Browse really did. Combining the paging with the vcr navigation is very good. I also wonder why dropdowns do not use paging by default. It would make a drop down with 10,000 customers easy to manage. My preferred UI is this..

------------------------------------------
search area

------------------------------------------
sorting combo
------------------------------------------
grid
[add] [edit] columns [delete]



------------------------------------------
--- paging ---

The user composes the search with a row per condition.
The sorting combo lets me explain the index more clearly in English such as Date of Hire+ Last Name+ First Name.

Since the results are paged, when the user wants to add, the added record has to appear in the list. That is because they may want to edit it again, and they should get feedback that the record was added, but without a dialog box, so there's no extra click. I opted to only show the last added record at the top of the current page. To do that, I grab the newly added record's Id

SELECT SCOPE_IDENTITY() id

and query for the newly added record and give it a fake row number of current page # -1 * number of items per page + .5.

This chunk of SQL becomes known as the INSERT_QUERY during an ADD operation. Note the UNION

	SELECT 
		Dnr_firstname, 
		Dnr_minit,
		Dnr_lastname,
		Dnr_Phone, 
		Dnr_Address1,
		Dnr_Zip,
		Dnr_eftcode, 
		emailaddress,
		Dnr_PK,
		Dnr_ID,
		(([PAGENUMBER,System]-1) * [PAGESIZE,System]) + .5 as RowNumber
	FROM [dbo].[EFTDonor] where Dnr_id=@id
UNION

For the first page the fake row number ends up being (1 - 1) * 20 rows per grid + .5 or just .5, making it the first row on the first page, second page etc.

I also create a variable called ExceptThis which contains the following:

AND Dnr_ID < > @id

then the INSERT_QUERY (with its UNION) is added to the rest of the command string yielding a result set (except for the newly added record), paged of course

WITH OrderedDonors AS
	([|INSERT_QUERY,Action] 
	SELECT 
		Dnr_firstname, 
		Dnr_minit,
		Dnr_lastname,
		Dnr_Phone, 
		Dnr_Address1,
		Dnr_Zip,
		Dnr_eftcode, 
		emailaddress,
		Dnr_PK,
		Dnr_ID,
		ROW_NUMBER() OVER (ORDER BY [SORTTAG,Dnr_ID]) as RowNumber
	FROM [dbo].[EFTDonor]
	where 1=1 [|ExceptThis,Action] @whrDnr_FullName
	) 
SELECT * 
FROM 
	OrderedDonors 
WHERE 
    RowNumber BETWEEN 
        (([PAGENUMBER,System]-1) * [PAGESIZE,System]) + .5
        and 
        ( [PAGENUMBER,System]  * [PAGESIZE,System])
ORDER BY RowNumber

Then in order to display the total number of records

Select count(*) as TotalCount from [dbo].[EFTDonor] where 1=1 [ExceptThis,Action] @whrDnr_FullName

In VFP I also use dynamic data session id switching to permit child forms to display data previously collected within the parent form's data session, saving lots of time otherwise wasted going back to the server.