Posted by Neil on 01/18/07 07:13

Larry,

I agree with what you wrote 100%. The application was inherited by me after
it was converted to an Access back end from an off-the-shelf product.
There's much that needs to be improved with it. One of the major changes
that we are looking to make is to change the way it works with records in
the way you describe. Bringing over tens of thousands of records is
ridiculous. I was considering giving the user options to work with small,
pre-defined sets of records based on business needs, with the additional
option of a custom set based on search criteria (with the sets being
compiled in the back end, of course, and then brought over). But your note
has made me rethink this. In what situations would the user need anything
*but* a custom set? So I'm rethinking that paradigm, and may just have the
user pull over whatever set of records they need. So thanks for that.

Getting back to the network situation, the problem only seems to manifest
itself in the WAN. The LAN users aren't experiencing this problem. And, as
noted, it only started about a week ago (after many years of the database
and WAN being up and running without this problem) and on the same day that
the WAN went down for several hours. So this tells me that SOMETHING
happened on that day that hasn't yet been rectified. But I know what the
network guy's going to say: everything's working fine now; he doesn't see
any problem with anything. And round and round we go......

Thanks,

Neil


"Larry Linson" <bouncer@localhost.not> wrote in message
news:iMCrh.3792$E35.2163@trnddc02...
>
> "Neil" <nospam@nospam.net> wrote in message
> news:XNvrh.12389$yx6.3307@newsread2.news.pas.earthlink.net...
>> OK, thanks. I guess I was thinking that, since this system has been in
>> place for years without these problems; and since these problems just
>> started last week when the WAN went down for a few hours; that perhaps
>> there was something on the network end that can be done to rectify it.
>> This has never been a problem before, so something must have happened to
>> cause it. The database hasn't changed very much in years.
>
> It is surprising how often only one record is needed for a particular
> business function, if it exists, or none, if it does not. Limiting the
> number of records retrieved by Query Criteria is a very good way to speed
> up client-server performance, and you'll never "lose" several hundred
> records on a one-record retrieval. A client-server application which
> retrieves hundreds or thousands of records, or more, and then "finds" the
> one of interest is not very efficient and effective.
>
> That said, the "fix" is to correct the LAN/WAN problems. I once observed a
> company who got a really noticeable improvement when they replaced about
> 95% of their network support staff. {:-) or :-(, depending on whether you
> were part of the new or the old staff} That said, because a LAN is
> totally within control of the network support team, it's much easier to
> fix than a WAN, which relies on external providers for some of its
> services.
>
> Larry Linson
> Microsoft Access MVP
>
>

[Back to original message]