File I/O ????? - Page 3


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 3 of 3 FirstFirst 123
Results 31 to 33 of 33

Thread: File I/O ?????

  1. #31
    Gary Nelson Guest

    Re: File I/O ?????

    Joe,


    > Fine, but do you still have hot spots in the balance table? When are you
    > going to show me the Access/DAO/Jet code that you claim proves searching
    > MDBs is "go to lunch" slow? Should we move this to some other forum?
    >


    This is the scenario: A couple of years ago I seriously considered using
    Access, so I built a routine that automatically ported from my database to
    Access. It was a little slow inserting a lot of keys into Access, but
    acceptable. The tests I did were with a 40,000 record database, which is
    small to medium size for the data we handle. Indexed searches were very
    good, but when it came to non-indexed searches (for example search for
    something like "*Jones*") I tried all kinds of different things, but
    nothing could get the search time down. Especially if the text we are
    looking for could be in more than one field. Perhaps you could show me what
    code you use that can do it quicker. By the way, catching is no good, as
    normally these are one time hits.

    Gary



  2. #32
    Joe \Nuke Me Xemu\ Foster Guest

    Re: File I/O ?????

    "Gary Nelson" <gn@contanet.es> wrote in message news:3aa35586@news.devx.com...

    > Joe,
    >
    >
    > > Fine, but do you still have hot spots in the balance table? When are you
    > > going to show me the Access/DAO/Jet code that you claim proves searching
    > > MDBs is "go to lunch" slow? Should we move this to some other forum?
    > >

    >
    > This is the scenario: A couple of years ago I seriously considered using
    > Access, so I built a routine that automatically ported from my database to
    > Access. It was a little slow inserting a lot of keys into Access, but


    Did you wrap the inserts into transactions? It helps! So does using a
    parameterized QueryDef instead of creating SQL statements which must be
    parsed anew for each insert. If you used a Recordset instead, creating
    aliases for the Field objects instead of always using MyRS!Whatever or
    ..Fields("Whatever") saves some time. The details matter.

    > acceptable. The tests I did were with a 40,000 record database, which is
    > small to medium size for the data we handle. Indexed searches were very
    > good, but when it came to non-indexed searches (for example search for
    > something like "*Jones*") I tried all kinds of different things, but
    > nothing could get the search time down. Especially if the text we are
    > looking for could be in more than one field. Perhaps you could show me what
    > code you use that can do it quicker. By the way, catching is no good, as
    > normally these are one time hits.


    What kinds of different things? Did you use Like or InStr? Did you use a
    SQL query, or did you open up the whole table and use FindFirst or maybe
    even loop through the records yourself? If you were searching for a last
    name starting with "Jones", did you store the entire name in one field,
    forcing yourself to do a table scan? If you were looking within free-text
    fields for words starting with "Jones", perhaps the full-text indexing
    code at <http://members.ricochet.net/~jfoster/> might have been of some
    interest. Heck, it even might have helped you search for anything having
    a "q", since you could scan the word list for "*q*", surely much less
    trouble than scanning all the text, and then join to the records having
    those words.

    --
    Joe Foster <mailto:jfoster@ricochet.net> Space Cooties! <http://www.xenu.net/>
    WARNING: I cannot be held responsible for the above They're coming to
    because my cats have apparently learned to type. take me away, ha ha!



  3. #33
    Gary Nelson Guest

    Re: File I/O ?????

    Joe,

    Have you tried any of those methods on a 100 MB database? (100 MB in one
    table) And I'm talking about close to a million records. Is there any
    method in Access that can pull a non indexed record in less than half a
    minute?

    One typical field is the entre description field. It is a 35 byte field
    that can contain practically anything, as there are thousands of different
    entry types. Some place in one of the records there might be an invoice
    number, someone's name, a bank account number, you name it, but someone has
    to find it. The routine I use now will take about 20 seconds in a million
    record database, which is about the limit to human patience. If Access can
    do it as fast I would take a second look.

    Gary




Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center