Re: Large Lists - Please read and comment

From: Jeff Grippe (jgrippe_at_hilldun.com)
Date: 03/17/05 

Date: Thu, 17 Mar 2005 10:31:51 -0500

Fred,

No disagreement there but I've got users who have been used to having "show
me everything" and have been working with it for close to 20 years. If it
weren't for the 2 million record limit I wouldn't even consider upsizing the
database. The performance of the VFP native tables is just fine.

As far as preventing wrong data from being entered, I'm doing the best I can
and constantly putting in new features to improve the accuracy but given the
volume of transactions, mistakes are inevitable and the ability to find them
is crucial.

"Fred Taylor" <ftaylor@mvps.org!REMOVE> wrote in message
news:eupYnMwKFHA.592@TK2MSFTNGP10.phx.gbl...
> 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?
>>
>>
>>
>>
>
>

Relevant Pages

  • Re: Large Lists - Please read and comment
    ... When I explain better techniques used with C/S, ... > upsizing the database. ... I have invoice and payment transactions for over 200 different ... >>> incorrect in a number of ways such as wrong company, wrong customer, ...
    (microsoft.public.fox.programmer.exchange)
  • Re: Large Lists - Please read and comment
    ... Prevent the entry of wrong customer, etc, as much as possible before hand. ... >>having to scroll through large lists of files in Windows explorer. ... >>Say your client is paying an invoice. ... > you can browse the entire database as the application allows now. ...
    (microsoft.public.fox.programmer.exchange)
  • Re: OOP - a question about database access
    ... >>and project so much better in SQL DBMSes than in ODBMSes, ... >>100x more bytes from the database, just because you want your objects to ... > a related invoice.. ... > assoication from the customer to the invoice collection and have done ...
    (comp.object)
  • Re: Large Lists - Please read and comment
    ... "Here are all 10 transactions that are approximately $200. ... > look at the data by customer for all of our clients. ... > paying or which invoice they are paying. ... > come from the same company that the invoice went to. ...
    (microsoft.public.fox.programmer.exchange)
  • Re: OOP - a question about database access
    ... >the invoice number and total cost from one place, customer name form ... >100x more bytes from the database, just because you want your objects to ... But then I wouldnt try and develop a system to handle ...
    (comp.object)
Quantcast