>>>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.
>
>snip
>
>If someone is looking for information about a customer named Yearwood, what is the likelihood the next customer they want to look at is named Yeats?

That's not the point. Databases are about sets. So why not permit navigation within the set? It's about workflow. If the user searches for Yearwood and there are 10 in the system, how do they decide which Yearwood they meant? If the user pulls a list of records starting with "Yea", sorted alphabetically then it's perfectly acceptable to navigate to the Yeats record. The user pulls all invoices for this month for a review. Are they supposed to print a report of them or print them all out and step through them manually?

I combine that with pagination so I don't send them 1,000 Yea records at once. The user should be able to narrow the focus - but not be expected to find exactly one record. That is too limiting.