The grid is good for which yeats do I want, but if the person is stepping thru records looking atm more data than would appear in one view of the grid they need the vcr.

I really like the dynamic datasession idea.

Cruising thru records VCR style, when/how do you determine at what point to bring down more records so the user is not kept waiting?

>Hi Tuvia
>
>I usually leave the VCR controls visible on the list page too. The VCR controls on the data screen prevent the user doing the hokey pokey jumping to the list and back to switch records. If they have seen the list and the "next" record they want is the 5th one down, they can switch to the list, select the record and return to the data screen or click next 5 times. Once they know about the vcr buttons, they also know they have a list of records, so it's no stretch of the imagination to use vcr to navigate the list - same thing as the downarrow key.
>
>
>
>>Excellent, thanks. The plan is the user can switch between a grid view and a data screen with the VCR controls, with the record coming up hot in the data screen.
>>
>>>>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.