Welcome to SPN

Register and Join the most happening forum of Sikh community & intellectuals from around the world.

Sign Up Now!

Huge DB, shouldn't be that big, doesn't compact

Discussion in 'Information Technology' started by vavroom@gmail.com, Jul 28, 2006.

  1. vavroom@gmail.com

    vavroom@gmail.com
    Expand Collapse
    Guest

    Hello again,

    I have a db that shouldn't be big, but weights in at 18MB just now. It
    was big before I started work on it, did a compact and repair, and came
    down to 2MB. I basically redrew the thing, and deleted the old tables,
    queries, and forms, looked at DB size, and it was 18MB again. So I did
    another compact/repair, only this time, it's staying at 18MB, which
    really shouldn't be that big.

    Any ideas what might be stopping the file reduction?
     
  2. Loading...

    Similar Threads Forum Date
    India Search term India: Huge Market for Google Breaking News Mar 13, 2013
    SALDEF SALDEF: Sold-out Gala a Huge Success! Sikh Organisations Oct 15, 2011
    Nature Huge Hole Opens in Arctic Ozone Layer Breaking News Oct 3, 2011
    India Anna Hazare's fast against corruption strikes huge chord Breaking News Apr 6, 2011
    Christianity Man Accused of Nuisance After Erecting Huge Lighted Crosses To Deter Atheists Interfaith Dialogues Feb 11, 2011

  3. Arvin Meyer [MVP]

    Arvin Meyer [MVP]
    Expand Collapse
    Guest

    Could be corrupted. The best way to cure it is to import all the objects
    into a new empty database.
    --
    Arvin Meyer, MCP, MVP
    Microsoft Access
    Free Access downloads
    http://www.datastrat.com
    http://www.mvps.org/access


    <vavroom@gmail.com> wrote in message
    news:1153360436.272280.120230@p79g2000cwp.googlegroups.com...
    > Hello again,
    >
    > I have a db that shouldn't be big, but weights in at 18MB just now. It
    > was big before I started work on it, did a compact and repair, and came
    > down to 2MB. I basically redrew the thing, and deleted the old tables,
    > queries, and forms, looked at DB size, and it was 18MB again. So I did
    > another compact/repair, only this time, it's staying at 18MB, which
    > really shouldn't be that big.
    >
    > Any ideas what might be stopping the file reduction?
    >
     
  4. vavroom@gmail.com

    vavroom@gmail.com
    Expand Collapse
    Guest

    Arvin, I just tried that when I came to see your response. Still porky
    file. :(

    I don't get it. It's not like I have that many records, nor even
    code...
     
  5. Albert D.Kallal

    Albert D.Kallal
    Expand Collapse
    Guest

    Hum, I have a application with about 160 forms, and 27,000 lines of code.
    The whole size after a compact is only 12 megs. As a mde it is only 6.8 megs
    in size.

    Perhaps you starting using some picture backgrounds for forms...they are not
    compressed...and they can bloat things in a hurry....


    --
    Albert D. Kallal (Access MVP)
    Edmonton, Alberta Canada
    pleaseNOOSpamKallal@msn.com
    http://www.members.shaw.ca/AlbertKallal
     
  6. vavroom@gmail.com

    vavroom@gmail.com
    Expand Collapse
    Guest

    Albert D.Kallal wrote:
    > Hum, I have a application with about 160 forms, and 27,000 lines of code.
    > The whole size after a compact is only 12 megs. As a mde it is only 6.8 megs
    > in size.


    I know!!! I've built much bigger applications that never reached that
    size even after 50K records...

    > Perhaps you starting using some picture backgrounds for forms...they are not
    > compressed...and they can bloat things in a hurry....


    No, I've not used one single image in forms or anywhere.
     
  7. vavroom@gmail.com

    vavroom@gmail.com
    Expand Collapse
    Guest

    Is it possible that a primary key in a table that contains 16
    characters would bloat the db size?
     
  8. John Vinson

    John Vinson
    Expand Collapse
    Guest

    On 20 Jul 2006 21:38:29 -0700, "vavroom@gmail.com" <vavroom@gmail.com>
    wrote:

    >Is it possible that a primary key in a table that contains 16
    >characters would bloat the db size?


    Only by approximately 32 characters times the number of records in the
    table. Not a huge amount (32MByte if you have a million records)...

    John W. Vinson[MVP]
     
  9. Arvin Meyer [MVP]

    Arvin Meyer [MVP]
    Expand Collapse
    Guest

    <vavroom@gmail.com> wrote in message
    news:1153456709.546266.136760@75g2000cwc.googlegroups.com...
    > Is it possible that a primary key in a table that contains 16
    > characters would bloat the db size?


    Not really. John answered correctly (32 bytes per row)

    But have you tried importing into a new, clean, empty database? That should
    cure the problem.
    --
    Arvin Meyer, MCP, MVP
    Microsoft Access
    Free Access downloads
    http://www.datastrat.com
    http://www.mvps.org/access
     
  10. vavroom@gmail.com

    vavroom@gmail.com
    Expand Collapse
    Guest

    Ahh, sorry for not following up sooner, I worked on a different, non
    Access based project this weekend (shameless plug: http://caughtya.org
    )

    > But have you tried importing into a new, clean, empty database? That should
    > cure the problem.


    Yes, I did. And it didn't :(

    Hmmm.
     
  11. Arvin Meyer [MVP]

    Arvin Meyer [MVP]
    Expand Collapse
    Guest

    If you imported everything into a new, empty database, and it didn't reduce
    the siz, the only other possibility that I can think og is that there ate 1
    or more images embedded in the project. Images can eat up incredible amounts
    of space in a database.
    --
    Arvin Meyer, MCP, MVP
    Microsoft Access
    Free Access downloads
    http://www.datastrat.com
    http://www.mvps.org/access

    <vavroom@gmail.com> wrote in message
    news:1153690139.384809.102220@m73g2000cwd.googlegroups.com...
    > Ahh, sorry for not following up sooner, I worked on a different, non
    > Access based project this weekend (shameless plug: http://caughtya.org
    > )
    >
    >> But have you tried importing into a new, clean, empty database? That
    >> should
    >> cure the problem.

    >
    > Yes, I did. And it didn't :(
    >
    > Hmmm.
    >
     
  12. vavroom@gmail.com

    vavroom@gmail.com
    Expand Collapse
    Guest

    > If you imported everything into a new, empty database, and it didn't reduce
    > the siz, the only other possibility that I can think og is that there ate 1
    > or more images embedded in the project. Images can eat up incredible amounts
    > of space in a database.


    I'm aware of how much size images eat, and I shy away from them because
    of that :(

    So, here's what I've done.
    1- Split the database
    2- Imported tables, one at a time, checking for DB size.
    3- Following this, I isolated the "culprit" to one table.

    This is the structure of this table:
    fldConcatID - Text - Primary key - Indexed, no dups - 17
    fldLName - Text - not indexed - 25
    fldFName - Text - not indexed - 25
    fldInitials - Text - not indexed - 5
    fldEmail - Text - not indexed - 50
    fldDept - Text - not indexed - 50
    fldPhone - Text - not indexed - 10
    fldCamp - Text - not indexed - 50
    fldCol - Number - not indexed - double

    The table contains 23K records, give or take. Alone in a DB, the DB
    weighs in at 3.64Mb Seems too much, doesn't it?
     
  13. Arvin Meyer [MVP]

    Arvin Meyer [MVP]
    Expand Collapse
    Guest

    Actually, that table could be as large as 6,578,000 bytes. If you figure
    that each field carried the maximum number of characters and that an index
    an a text field can double it's size, and that Unicode doubles the bytes of
    each character in a text field, it would be that large.
    --
    Arvin Meyer, MCP, MVP
    Microsoft Access
    Free Access downloads
    http://www.datastrat.com
    http://www.mvps.org/access

    <vavroom@gmail.com> wrote in message
    news:1153879717.310652.152720@h48g2000cwc.googlegroups.com...
    >> If you imported everything into a new, empty database, and it didn't
    >> reduce
    >> the siz, the only other possibility that I can think og is that there ate
    >> 1
    >> or more images embedded in the project. Images can eat up incredible
    >> amounts
    >> of space in a database.

    >
    > I'm aware of how much size images eat, and I shy away from them because
    > of that :(
    >
    > So, here's what I've done.
    > 1- Split the database
    > 2- Imported tables, one at a time, checking for DB size.
    > 3- Following this, I isolated the "culprit" to one table.
    >
    > This is the structure of this table:
    > fldConcatID - Text - Primary key - Indexed, no dups - 17
    > fldLName - Text - not indexed - 25
    > fldFName - Text - not indexed - 25
    > fldInitials - Text - not indexed - 5
    > fldEmail - Text - not indexed - 50
    > fldDept - Text - not indexed - 50
    > fldPhone - Text - not indexed - 10
    > fldCamp - Text - not indexed - 50
    > fldCol - Number - not indexed - double
    >
    > The table contains 23K records, give or take. Alone in a DB, the DB
    > weighs in at 3.64Mb Seems too much, doesn't it?
    >
     
  14. vavroom@gmail.com

    vavroom@gmail.com
    Expand Collapse
    Guest

    Arvin Meyer [MVP] wrote:
    > Actually, that table could be as large as 6,578,000 bytes. If you figure
    > that each field carried the maximum number of characters and that an index
    > an a text field can double it's size, and that Unicode doubles the bytes of
    > each character in a text field, it would be that large.


    All right, solved then. Don't particularly like it, but... not much
    of a choice.

    Thanks for helping me problem solve this Arvin :)
     
  15. Albert D.Kallal

    Albert D.Kallal
    Expand Collapse
    Guest


    > The table contains 23K records, give or take. Alone in a DB, the DB
    > weighs in at 3.64Mb Seems too much, doesn't it?


    Well, just adding up the sizes of the text fields, you get about 240
    characters per record.

    240 X 23,000 = 5,336,000

    So, that is 5 megs. Considering that all fields are not full, and you are in
    at the mid 3 meg range..that sounds reasonable to me....

    You original database of 18 megs sounded too large, but 3.5 megs for 23,000
    records sounds just fine...

    --
    Albert D. Kallal (Access MVP)
    Edmonton, Alberta Canada
    pleaseNOOSpamKallal@msn.com
    http://www.members.shaw.ca/AlbertKallal
     

Share This Page