Unusually Large .accde File (1 Viewer)

LWoods · Mar 19, 2012

Hi All,

I created a database for a department in our company to track the projects they work on (15+ users). In order to protect the data and design, I split the database and also created an .accde file for production that the staff use from a shared location.

Today, I noticed that the production .accde file was unusually large at 128MB. My back-up .accde file is 3.3MB, so I tried using that to overwrite the production db, which worked; however, the file size increases back to the 128MB once someone opens it again. The back-end (_be.accdb) file is about 5.6MB and my database pre-split was only 31.3MB.

The database has been in use since the beginning of 1st quarter and I've never seen this before. Any ideas why this might be happening?

Many thanks!
-L

NigelShaw · Mar 19, 2012

Hi,

has your application by chance, got a MS Flexgrid in it?

Cheers

Nidge

LWoods · Mar 20, 2012

Hi Nigel -- thanks so much for your response.

I've never come across the MS FlexGrid control before. I've just done some reading up on it and I'm certain that my database does not have the FlexGrid attached.

Thanks!
-L

RossWindows · Mar 20, 2012

.accde file for production that the staff use from a shared location.

They're all using the same single .accde?
as opposed to each user being given their own .accde?

That could be part of the problem.

LWoods · Mar 21, 2012

Hi Ross -- yes, they are all using the same .accde file and I agree that the bloating could potentially be caused by many users in the database at the same time. I'm just not sure why it is happening now, after 3 months of the same process being used.

As it is not currently affecting production, I will continue to monitor the file size to try to determine what could be causing the bloating.

That said, I know that the db is in use when the locking file is present (.laccdb), but is there any way to see which users have the db open?

Many thanks!
-L

RossWindows · Mar 21, 2012

I used a scheme where I have my master design copy that nobody touches period.
Then there is my primary .accde but nobody accesses it directly.
Each user has a shortcut on their desktop which runs a batch file.
The job of the batch file is to make a copy of the current primary .accde and paste it into a 'Users/%UserName%' sub-folder on the file server.
Then it launches the new copy.
This allows me to see at a glance how many users actually have the database open since their all in the same 'Users/' folder.
Performance has never been an issue but then again, none of my compiled front-ends are more than 5-10MB.

LWoods · Mar 21, 2012

Well, I'm sold! You scheme sounds fantastic and I have already started doing some research on batch files to expand my knowledge base in this area.

I would love to adopt this process, but can I clarify: Would it be possible to have one batch file located in a shared drive for all users to run from? Or is it necessary to provide each user with their own? I'm fairly certain that our "powers that be" won't want to change the process.

-L

Simon_MT · Mar 21, 2012

You should have the Front End on each users PC because the application can be processed locally. This may not matter to much these days but there is no real need to tie up the server unnecessarily.

To achieve this you MUST use persistency i.e. a table must be open all the time between the Front End and the Back End on the Server. This is could contain only one record that is all that is required. It can be more useful like holding the organisations details or global values like base currency.

Without the persistency data calls can be tedious. I still think that filtering record sets is equally important to optimise speed so rather than load every Client and then filtering the content on open. This again reduces network traffic.

Simon

RossWindows · Mar 21, 2012

In most cases Simon_MT is correct in that you want each user to have their own LOCAL copy. In my case, we are in a terminal server environment, so whether the user's copy was on the ts or the fs, makes no difference. (they're practically on the same box).

To answer your question about the batch file, Lwoods. I have one batch file on the file server. Each user has a shortcut to the batch file. This allows you to make a change to that one batch file for whatever reason and the only thing the user has to do is reopen their application via their shortcut. This way, you can deploy updates seamlessly that take effect the next time the user restarts their app.

Simon_MT · Mar 21, 2012

Aah - a Terminal Server you are are quite correct but each user should still have there own copy on the Terminal Server. Persistency applies if the Back End is on a different server. Generally, a Terminal Server is configured with additional memory to allow for multiple instances of applcations.

Simon

Simon

LWoods · Mar 23, 2012

Hi Ross -- I completely agree with your solution. Ultimately, I don't want to have to distribute new copies of the front-end every time a change is made. And as you said, having the shortcut is a great tool for seamless updates.

We had a very tight deadline for getting this db in use for production, so we had to hold off on some db administrator features that weren't critical. Now that the production end of the db is complete and the users are able to input their records, I am updating the administrator functions as needed. That’s why I prefer to maintain one front-end, as I have to be able to simply overwrite the existing front-end with the updated version, without disrupting the users.

Many thanks for everyone's input.

Have a great weekend!
-L

adrianscotter · Jul 4, 2019

I know this is an old, old post but...

I've been looking for an answer for this for hours. I couldn't find anything out from my old mate Google, however, I've just been deleting redundant forms in my errant DB and after deleting a form that handles PDF files, VOILA!!! The DB.accde file is down from 19 MB to 5 MB, some considerable saving for 1 form that displayed a single, A4 PDF (and a simple, text only PDF at that!)

No more :banghead:

gemma-the-husky · Jul 4, 2019

I have databases around 100Mb, but they are massive. Thousands of queries, and hundreds of forms and reports.

I am never unduly bothered. They also grow a little as temporary queries get created.

It is what it is, as they say on Love Island

adrianscotter · Jul 5, 2019

gemma-the-husky said:
I have databases around 100Mb, but they are massive. Thousands of queries, and hundreds of forms and reports.

I am never unduly bothered. They also grow a little as temporary queries get created.

It is what it is, as they say on Love Island

Oh I do understand these files can get big, but this should be around 4 or 5 megs tops, not 20! Therefore, yes, I’m bothered, I don’t like anything unusual happening with my DB files. I’ve always found unusual equates to ‘oh crap,’

adrianscotter · Jul 5, 2019

gemma-the-husky said:
I have databases around 100Mb, but they are massive. Thousands of queries, and hundreds of forms and reports.

I am never unduly bothered. They also grow a little as temporary queries get created.

It is what it is, as they say on Love Island

And 'Love Island'? Really?

Unusually Large .accde File (1 Viewer)

LWoods

Registered User.

NigelShaw

Registered User.

LWoods

Registered User.

RossWindows

Que?

LWoods

Registered User.

RossWindows

Que?

LWoods

Registered User.

Simon_MT

Registered User.

RossWindows

Que?

Simon_MT

Registered User.

LWoods

Registered User.

adrianscotter

Registered old fart!

gemma-the-husky

Super Moderator

adrianscotter

Registered old fart!

adrianscotter

Registered old fart!

Similar threads

Users who are viewing this thread