Re: Large Lists - Please read and comment

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: Fred Taylor (ftaylor_at_mvps.org!REMOVE)
Date: 03/18/05


Date: Thu, 17 Mar 2005 18:21:40 -0700

What 2 million record limit? VFP has no such limitation. The limit is 2GB
per file, (2GB for the .DBF, 2GB, for the .FPT, 2GB for the .CDX, etc).

-- 
Fred
Microsoft Visual FoxPro MVP
"Jeff Grippe" <jgrippe@hilldun.com> wrote in message 
news:113j8nn64rm6m6d@news.supernews.com...
> 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: Date / Autonumber anomaly
    ... start a brand new database beginning with new invoice/record numbers. ... think the corruption may be due to the age and size of the database. ... corruption doesn't get carried forward because it exists in your invoice ... but the intent of Autonumber is to ...
    (comp.databases.ms-access)
  • Re: Date / Autonumber anomaly
    ... In that case, try creating a new, empty database and importing ... corruption doesn't get carried forward because it exists in your invoice ... entering, displaying, and editing the data. ... but the intent of Autonumber is to ...
    (comp.databases.ms-access)
  • Re: Split database continued
    ... The code for creating a one off invoice takes 12 seconds with the database ... Private Sub Create_New_Invoice_Click ... Dim Invs As DAO.Recordset ...
    (microsoft.public.access.formscoding)
  • Re: Date / Autonumber anomaly
    ... I suggest, for your sequential invoice number, that you use the DMAX domain ... aggregate function, to which you add one, rather than relying on Autonumber. ... Bob's correct -- database size is not a known cause of corruption. ...
    (comp.databases.ms-access)
  • Re: Problem with a template from the MS Office website
    ... noted and have resolve them and reposted them the updated db to our web. ... database. ... I suspect it will be ages before my Access and VBA ... and controls so that the Invoice Report ...
    (microsoft.public.access.reports)