Posted by Steve Jorgensen on 10/30/05 23:46

On Sun, 30 Oct 2005 20:33:30 GMT, "Neil" <nospam@nospam.net> wrote:

>
>"Steve Jorgensen" <nospam@nospam.nospam> wrote in message
>news:um7am1p16ht249oqhnb700uv2qg2007go4@4ax.com...
>> On Sun, 30 Oct 2005 16:59:45 GMT, "Neil" <nospam@nospam.net> wrote:
>>
>>>Both table have PKs; and the join is on the PKs (the main table has a
>>>single-field PK; and the selections table has two field -- the
>>>corresponding
>>>ID value from the main table combined with the machine name).
>>>
>>>The 13 second form open time (with the 50k record selections table in the
>>>front end joined heterogeneously with the 50k record main table in the
>>>back
>>>end) is over a WAN. The LAN users get much better performance.
>>
>> How many records are being returned to the form, and what kind of
>> recordset
>> are you using? Is any of your links to a view? If linking to a view, did
>> you
>> select a logical primary key when you created the link?
>>
>
>50,000; dynaset; yes, the two tables are combined in the back end using a
>view; yes.

You're returning 50,000 rows to a form! No - that's not how client/server
works. You give users an interface that lets them pick what reasonable subset
or roll-up of the data they want to see, then navigate or drill-down form
there.

The point of SQL Server is that searching and filtering happens on the server
side and small result sets are returned to the client as requested.

>But regarding the slowness issue, I think it's resolved. See my other post
>in this thread. Thanks.

Solved? Perhaps, with a single user at a time, and no competing traffic on
the network. A design that returns 50,000 rows to a client in one result set
is findamentally flawed.

[Back to original message]