huge MDB with very little in it

[Graham Charles]

I've got an MDB (Access 2000 format, using Access 2003 to create and
run) that's just enormous, even though there are"

0 tables,
3 pass-through queries
2 small forms
2 small reports
5 modules of about 10K

The database is an unshrinkable 20MB. Obviously, compact and repair
isn't helping or I wouldn't be here. All I can imagine is that Access
caches some of the data from the pass-through queries? (They are
designed to return just a few rows each, though, so I'm not sure why
that would be.)

Any ideas as to how to shrink this thing down? (I'm deploying via
e-mail, so 20 MB is a bit much, and I'd prefer not to have to do user
education around zips and such if possible.)

Thanks.

g.

[Gabriele Bertolucci]

> I've got an MDB (Access 2000 format, using Access 2003 to create and

run) that's just enormous, even though there are"

0 tables,
3 pass-through queries
2 small forms
2 small reports
5 modules of about 10K
The database is an unshrinkable 20MB. Obviously, compact and repair
isn't helping or I wouldn't be here. All I can imagine is that Access
caches some of the data from the pass-through queries? (They are
designed to return just a few rows each, though, so I'm not sure why
that would be.)

Any ideas as to how to shrink this thing down? (I'm deploying via
e-mail, so 20 MB is a bit much, and I'd prefer not to have to do user
education around zips and such if possible.)

You may try to create a new empty database and then import all objects from
the old database.

--
PBsoft di Gabriele Bertolucci
www.pbsoft.it
skype: pbsoftsolution

[Nick Coe \(UK\)]

In
news:11**********************@j33g2000cwa.googlegr oups.com,
Graham Charles typed:

I've got an MDB (Access 2000 format, using Access 2003 to
create and run) that's just enormous, even though there
are"

0 tables,
3 pass-through queries
2 small forms
2 small reports
5 modules of about 10K

The database is an unshrinkable 20MB. Obviously, compact
and
repair isn't helping or I wouldn't be here. All I can
imagine
is that Access caches some of the data from the
pass-through
queries? (They are designed to return just a few rows
each,
though, so I'm not sure why that would be.)

Any ideas as to how to shrink this thing down? (I'm
deploying
via e-mail, so 20 MB is a bit much, and I'd prefer not to
have
to do user education around zips and such if possible.)

Thanks.

g.

Had a similar problem a long time ago - I can only suggest a
couple of things from memory for you to investigate and
experiment with.

Import all objects into a new application mdb - (this worked
for me once).
Get Jetcomp.exe for Jet 4 from the MSFT site and try it.
Try a \decompile and then recompile - I doubt this will make
any difference but must be worth a try.

References:
Tony Toews page on decompile
http://www.granite.ab.ca/access/decompile.htm

MVPS
http://www.mvps.org/access/bugs/bugs0008.htm

Michka
http://www.trigeminal.com/usenet/usenet004.asp

--
Nick Coe (UK)
http://www.alphacos.co.uk/
AccHelp is now free/donateware

[Graham Charles]

Thanks much to both of you; neither method was successful. Through
experimenting, I found that each of my two "small" reports takes up 8MB
or so. The pass-through query it draws from has extremely wide rows
(200 or so columns of mostly text data), so I'm sticking with my
caching theory.

Cheers,

g.

[(PeteCresswell)]

Per Graham Charles:

Thanks much to both of you; neither method was successful. Through
experimenting, I found that each of my two "small" reports takes up 8MB
or so. The pass-through query it draws from has extremely wide rows
(200 or so columns of mostly text data), so I'm sticking with my
caching theory.

No images on reports or screens, right?
--
PeteCresswell

[Chuck]

On 16 Mar 2006 23:11:34 -0800, "Graham Charles" <gr****@aiid.com> wrote:

That is Access's overhead. The amount of overhead is dependent on the version
of Access you are using. Create a new, clean, empty database and check the
size.

Just a wizard proder
Chuck
--

I've got an MDB (Access 2000 format, using Access 2003 to create and
run) that's just enormous, even though there are"

0 tables,
3 pass-through queries
2 small forms
2 small reports
5 modules of about 10K

The database is an unshrinkable 20MB. Obviously, compact and repair
isn't helping or I wouldn't be here. All I can imagine is that Access
caches some of the data from the pass-through queries? (They are
designed to return just a few rows each, though, so I'm not sure why
that would be.)

Any ideas as to how to shrink this thing down? (I'm deploying via
e-mail, so 20 MB is a bit much, and I'd prefer not to have to do user
education around zips and such if possible.)

Thanks.

g.

[Lyle Fairfield]

Do the reports have images?

[Tim Marshall]

Graham Charles wrote:

All I can imagine is that Access
caches some of the data from the pass-through queries? (They are
designed to return just a few rows each, though, so I'm not sure why
that would be.)

Never encountered this myself and I use PTQs for Access FEs on an Oracle
DB with millions of records (though of course the PTQs don't return
nearly that many) all the time. Might be different for other back end
database types, though.
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "What's UP, Dittoooooo?" - Ditto

[Graham Charles]

Right, nothing. Well, there were, but that was the first thing I
deleted in attempting to suss this out.

[Tim Marshall]

Graham Charles wrote:

Right, nothing. Well, there were, but that was the first thing I
deleted in attempting to suss this out.

Ah ha! What about a decompile? I've found in my A2003 apps that the
decompile is almost compulsory, especially if images have been involved.
Does some dramatic things file size wise.

Lyle will suggest the save as text route which he has said here recently
is superior or at least as good as decompile, IIRC.

--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "What's UP, Dittoooooo?" - Ditto

[Larry Linson]

"Tim Marshall" wrote

Lyle will suggest the save as text route
which he has said here recently
is superior or at least as good as
decompile, IIRC.

I agree with Lyle on this one. When you Save To Text, it is "decompiled",
and more...

Larry Linson

[Graham Charles]

Well, thanks all, for all your replies. I think it was the pictures
from the reports that were doing it, even though I'd removed them.
(Perhaps some of the embedded data got retained somehow?) Creating a
new database and importing the objects didn't work; the new database
was similarly bloated. What did work was opening the old report in
design mode, selecting all the existing controls and copying them into
a new report, then deleting the original report.

I'm thinking this was a fluke -- position of the moon when I was
deleting the pictures or something -- because I've never experienced
this behavior before and I've been creating Access DBs for over a
decade.

Thanks again,

g.

[(PeteCresswell)]

Per Graham Charles:

What did work was opening the old report in
design mode, selecting all the existing controls and copying them into
a new report, then deleting the original report.

One more tidbit: if somebody just *has* to have an image in a report or on a
screen, one might be tempted to use a JPEG because JPEGs are smaller. But the
opposite seems tb true: JPEGS take up a whole lot more room than Windows .BMPs.
--
PeteCresswell

[David W. Fenton]

"(PeteCresswell)" <[e-mail]> wrote in
news:6m********************************@4ax.com:

Per Graham Charles:

What did work was opening the old report in
design mode, selecting all the existing controls and copying them
into a new report, then deleting the original report.

One more tidbit: if somebody just *has* to have an image in a
report or on a screen, one might be tempted to use a JPEG because
JPEGs are smaller. But the opposite seems tb true: JPEGS take up
a whole lot more room than Windows .BMPs.

It's not a whole lot more room. Just the size of the bitmap that is
produced from unpacking the JPG plus the original JPG file. If you
use a bitmap, you don't have the overhead of storing the original
JPG.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[Randy Harris]

David W. Fenton wrote:

"(PeteCresswell)" <[e-mail]> wrote in
news:6m********************************@4ax.com:

Per Graham Charles:

What did work was opening the old report in
design mode, selecting all the existing controls and copying them
into a new report, then deleting the original report.

One more tidbit: if somebody just *has* to have an image in a
report or on a screen, one might be tempted to use a JPEG because
JPEGs are smaller. But the opposite seems tb true: JPEGS take up
a whole lot more room than Windows .BMPs.

It's not a whole lot more room. Just the size of the bitmap that is
produced from unpacking the JPG plus the original JPG file. If you
use a bitmap, you don't have the overhead of storing the original
JPG.

And, it's especially true if you import a large jpeg and scale it down.
It stores the whole thing, not just the scaled down image.

--
Randy Harris
tech at promail dot com
I'm pretty sure I know everything that I can remember.

[Graham Charles]

Probably exactly what was going on in my case, although I'm not sure
why the data remained after I deleted the picture.

Oh, well. Problem solved, in any case.

g.