 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
MS Access Forum / Developer Toolkits / May 2005MDB file growing
Hi, I am new to Access programming. We recently split our Access database in two. Our database is rather large and we are having all kinds of speed and reliability issues. I noticed that our front-end database keeps growing in our production environment. After running the compress, it is about 6.5 megs. After the users go at it for a while, it will be somewhere around 145 megs. Since the data is in a separate database, can anyone explain to me why I would be seeing this behavior and if this could help explain the problems we're having with speed? Any help would be greatly appreciated. Hi Jim, Is each user running a separate copy of the front end? Immanuel Sibero > Hi, I am new to Access programming. We recently split our Access database > in two. Our database is rather large and we are having all kinds of speed [quoted text clipped - 4 lines] > I would be seeing this behavior and if this could help explain the problems > we're having with speed? Any help would be greatly appreciated. Thank you very much for answering...currently, all users (about two dozen or so) are running the same copy off of a network drive. It is our intention in the very near future to start having each user run it off of their own local copy. > Hi Jim, > [quoted text clipped - 16 lines] > problems > > we're having with speed? Any help would be greatly appreciated. Jim, Well, I guess you could anticipate my response.. :-) Two dozens of simultaneous users is a lot. Your front end setup is documented as one of the more common causes of corruption. I would resolve this first before looking elsewhere. Immauel Sibero > Thank you very much for answering...currently, all users (about two dozen or > so) are running the same copy off of a network drive. It is our intention in [quoted text clipped - 21 lines] > > problems > > > we're having with speed? Any help would be greatly appreciated. >It is our intention in >the very near future to start having each user run it off of their own local >copy. I'd edit that from "very near future" to "immediately, without delay"... <g> That should solve the bulk of your problem right there. John W. Vinson[MVP] besides the other comments about sharing the fe file, and since you say you are new to access there are a couple basic things. Access does not automatically recover temporarily used space in mdb files. So when running queries or other operations that require temporary storage the mdb file grows but never shrinks. on the frontend you can set the option to compact and repair on closing to recover that space, at least as long as it isn't shared. for the backend file you are probably best off manually compacting it on some schedule when no one is using it. > Hi, I am new to Access programming. We recently split our Access database > in two. Our database is rather large and we are having all kinds of speed [quoted text clipped - 4 lines] > I would be seeing this behavior and if this could help explain the problems > we're having with speed? Any help would be greatly appreciated. This is right along the lines of a problem I'm having with a seemingly corrupted backend. I've got a split configured application used by a client of mine. One of the features I've got implemented is periodic backend compression. When exiting the client, the program checks a date that I have stored in a table on the backend. If 3 weeks have elapsed between the stored date and now(), I advise the user that the backend will be compressed. The program then makes a backup copy of the backend - then compresses it. Every once in a while, data in tables gets skewed. When adding new records, data gets plugged into incorrect fields. Does anyone know what causes this and if there's anything that can be done? Thanks in advance. Bnielsen > besides the other comments about sharing the fe file, and since you say you > are new to access there are a couple basic things. Access does not [quoted text clipped - 19 lines] > problems > > we're having with speed? Any help would be greatly appreciated. I don't believe automatic compression is a good idea in ANY circumstances. In the first place the BE is by definition multi-user, so how do you know everyone is out? (in any case, it is open by your FE) In the second place, if it's large it should be done local and not over the network (for reliability as well). In the third place, it may have subtle corruptions which do not otherwise prevent it from working. It's a good idea to advise the user, but leave it at that. It may well be your case that the BE requires compacting every 3 weeks, OTOH I have customers who don't unduly complain if the BE is not compressed in a year! Chris > This is right along the lines of a problem I'm having with a seemingly > corrupted backend. I've got a split configured application used by a client [quoted text clipped - 8 lines] > > Bnielsen Thanks for the note. You're probably right.....3 weeks may be excessive. When the compression occurs, there are no active tables going on. it happens just before the app closes. I am going to take your suggestion and just give them a reminder - and make that every 3-4 months at that. Thanks again. > I don't believe automatic compression is a good idea in ANY circumstances. In > the first place the BE is by definition multi-user, so how do you know [quoted text clipped - 22 lines] > > > > Bnielsen |
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.