Re: Large Lists - Please read and comment

Tech-Archive recommends: Fix windows errors by optimizing your registry

From: Jan (Nomail_at_Nowhere.com)
Date: 03/17/05 

Date: Fri, 18 Mar 2005 10:41:45 +1100

Ok Guys,

I've read all the posts on this topic and mostly the thrust is :-
- We want to use large lists (some of us anyway)
- Customers are used to the look and feel
- What happens when the data outgrows our database capabilities
- How can we do this smarter.
Some very good suggestions were made and I wouldn't disagree with any of
them entirely.

Here is my take on it.

Firstly, if you have that many companies entrenched in one database you have
maximum exposure to calamity when data corruption occurs or hardware fails,
so split the companies into their own database (regardless of vfp dbc or C/S
Sql) and house these companies on separate machines as far as practical
(hardware & OS is cheap compared to data). Structure the app to select the
company and thus access the appropriate server/database.

Secondly, some parts of an app work as lists (large or otherwise) other
parts should be selected ie. Products or customers can be lists, but only
when requested so allow the user to search for a customer but give him a
button to open the list. In the case of products allow the user to key in a
product code and once again give them the option of opening the list. List
should always allow searches on multiple keys. So taking this further, when
maintain product or customer details use a list (grid with a search
facility). When processing transactions use a search box with a list
available via a button. This approach avoids queries and requeries of the
data. As for processing data incorrectly the access to that data should
ensure that it is difficult to post transactions to the wrong
company/customer. This approach will not alienate those who are used to a
purely list driven approach.

Lastly, to ensure data is captured correctly, use your app as a dialogue, so
You want to pay your "ABC" bill, what is your name, Mr Smith what is your
phone number? Thanks , your current balance appears to be .... is this
correct. how much are you paying ... and so on.

Jeff, in your specific situation, obviously some major redevelopment would
be of immense benefit, but you probably could play with these suggestions on
a small scale and try it out on your users without "imposing" a new solution
on them.

Well that my tuppence worth.

Rgds
Jan
"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?
>
>
>
>

Quantcast