 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
MS Access Forum / General 1 / March 2006huge MDB with very little in it
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. > I've got an MDB (Access 2000 format, using Access 2003 to create and > run) that's just enormous, even though there are" [quoted text clipped - 13 lines] > 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 In news:1142579494.146819.123370@j33g2000cwa.googlegroups.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 [quoted text clipped - 25 lines] > > 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  SignatureNick Coe (UK) http://www.alphacos.co.uk/ AccHelp is now free/donateware 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. 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? SignaturePeteCresswell Right, nothing. Well, there were, but that was the first thing I deleted in attempting to suss this out. > 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. SignatureTim http://www.ucs.mun.ca/~tmarshal/ ^o< /#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake /^^ "What's UP, Dittoooooo?" - Ditto > 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 Do the reports have images? 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" [quoted text clipped - 18 lines] > >g. > 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. SignatureTim http://www.ucs.mun.ca/~tmarshal/ ^o< /#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake /^^ "What's UP, Dittoooooo?" - Ditto 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. 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. SignaturePeteCresswell > Per Graham Charles: >>What did work was opening the old report in [quoted text clipped - 5 lines] > 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. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ >> Per Graham Charles: >>> What did work was opening the old report in [quoted text clipped - 9 lines] > 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. SignatureRandy Harris tech at promail dot com I'm pretty sure I know everything that I can remember. 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. |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.