Re: Large Lists - Please read and comment
From: Fred Taylor (ftaylor_at_mvps.org!REMOVE)
Date: 03/17/05
- Next message: Ook: "Re: Large Lists - Please read and comment"
- Previous message: Fred Taylor: "Re: procedure with or without a parameter?"
- In reply to: Jeff Grippe: "Large Lists - Please read and comment"
- Next in thread: Jeff Grippe: "Re: Large Lists - Please read and comment"
- Reply: Jeff Grippe: "Re: Large Lists - Please read and comment"
- Messages sorted by: [ date ] [ thread ]
Date: Thu, 17 Mar 2005 08:08:17 -0700
Prevent the entry of wrong customer, etc, as much as possible before hand.
<s>
You really have to get off of the "show me everything" track for an
effective client server approach. Use multiple pieces of info to narrow the
search.
-- Fred Microsoft Visual FoxPro MVP "Jeff Grippe" <jgrippe@hilldun.com> wrote in message news:113j3cjgguclibf@news.supernews.com... > Hello, > > I am starting a new thread with a snippet from another topic. This > concerns database design and user interaction so I thought it might be > good to hear from some of you about this topic. > > Dan Freeman said... >>When you think of it, large lists aren't very practical anyway. I *hate* >>having to scroll through large lists of files in Windows explorer. > >>Say your client is paying an invoice. Chances are good they have the >>invoice >>in their hands so ask them who they're paying and bring back the >>outstanding >>invoices for that vendor. > > My problem is that there are features that can only be implemented when > you can browse the entire database as the application allows now. I will > grant you that these features can be "wedged" into a client/server > database but the "full table browse" approach is more natural. > > An example: > My system is a multi-company (over 200 companies) accounts receivable > system. I have invoice and payment transactions for over 200 different > companys each of whom sells to thousands of customers (so it is no > surprise that I will soon be facing the 2,000,000 record barrier). > > Transactions are often incorrectly posted and must be found. They can be > incorrect in a number of ways such as wrong company, wrong customer, wrong > amount, wrong invoice number, wrong check number, wrong check amount, > wrong invoice data, etc. > > My search utility is basically a grid control (browse) of the entire table > that allows sorting and searching by any of these fields. Users search for > the information and then browse through information that is close. Because > everything is done with DBFs and index tags there is no delay when they > change search criteria and sort order. > > An SQL database that demands requerying for each search would slow down > the application and provide fewer options. > > How do some of you C/S people or opponents of "Large Lists" approach this > problem in an SQL type of environment. > > Have any of you had to transition users from "Large List" applications to > C/S applications? How did it go? > > > >
- Next message: Ook: "Re: Large Lists - Please read and comment"
- Previous message: Fred Taylor: "Re: procedure with or without a parameter?"
- In reply to: Jeff Grippe: "Large Lists - Please read and comment"
- Next in thread: Jeff Grippe: "Re: Large Lists - Please read and comment"
- Reply: Jeff Grippe: "Re: Large Lists - Please read and comment"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
Loading