UtterAccess.com
X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
 
   Reply to this topicStart new topic
> Database.mdb, Access 2013    
 
   
SomekindaVB
post Jan 11 2018, 07:19 PM
Post#1



Posts: 264
Joined: 15-December 16



hello all.

I have a very curious issue and I don't know how to even start to address it.

Whenever I close down my access project the name is changed from It's correct name to Database.mdb. For example:

CODE
MylargeBD.acccdb => database.mdb


This is bizzare and very annoying. how do I fix this?

Cheers
Go to the top of the page
 
GroverParkGeorge
post Jan 11 2018, 08:47 PM
Post#2


UA Admin
Posts: 33,502
Joined: 20-June 02
From: Newcastle, WA


Do you have "compact on close" set?

Attached File  COmpactOnClose.jpg ( 307.55K )Number of downloads: 3


This is consistent with what happens when a Compact & Repair fails to complete properly, leaving the temporary file called "database.mdb" in the folder.

However, the original should not be lost in the process.

--------------------
My Real Name Is George. Grover Park Consulting is where I do business.
How to Ask a Good Question
Beginning SQL Server
Visit My Blog on Facebook
Go to the top of the page
 
SomekindaVB
post Jan 11 2018, 09:08 PM
Post#3



Posts: 264
Joined: 15-December 16



Oddly it wasn't set at all.

The even more oddly, I set it, and it ran through it compact sequence, created the database.mdb file, then changed it to the original file name. Now I only did this once so, didn't correctly test, but it is operating all very strangely.
Go to the top of the page
 
GroverParkGeorge
post Jan 11 2018, 09:12 PM
Post#4


UA Admin
Posts: 33,502
Joined: 20-June 02
From: Newcastle, WA


That part is perfectly normal.

So you are saying that you open a database called, for example, "MyLargeDB.mdb". And after you have worked with it for a while, you close it.
And at that point there is no longer a file called "MyLargeDB.mdb" in the folder, having been replaced by one called "database.mdb"?


--------------------
My Real Name Is George. Grover Park Consulting is where I do business.
How to Ask a Good Question
Beginning SQL Server
Visit My Blog on Facebook
Go to the top of the page
 
SomekindaVB
post Jan 11 2018, 10:33 PM
Post#5



Posts: 264
Joined: 15-December 16



Yes, you have summarised the problem accurately.

My front end db is almost 30 Mb. when I close it, it creates a database.mdb file in the same directory. Then, when that file reaches the same size as the original it seems to remove the original, then rename itself. which is what I presume is the compaction process taking place.

If the compact on close is not checked, it creates the database.mdb file, then removes the original.

I turned off the compact on close only to speed things up, since the front end doesn't really need to be compacted or repaired.
Go to the top of the page
 
GroverParkGeorge
post Jan 12 2018, 12:26 AM
Post#6


UA Admin
Posts: 33,502
Joined: 20-June 02
From: Newcastle, WA


That's what I thought. Something is causing the compact & repair to fail, leaving the database.mdb intact. Why that's happening is not clear, of course, because we can't see the process on your computer.


Does this happen every time? If you let it just complete without touching any of the files, does the same thing happen?

This could be the result of corruption in the mdb. And you say this is the Front End in a split database implementation?

Does the VBA compile? Have you observed any anomalies in performance?

One that might be helpful is to create a new, empty mdb and import all objects from this one. Another would be to use decompile .

--------------------
My Real Name Is George. Grover Park Consulting is where I do business.
How to Ask a Good Question
Beginning SQL Server
Visit My Blog on Facebook
Go to the top of the page
 
WildBird
post Jan 12 2018, 01:35 AM
Post#7


UtterAccess VIP
Posts: 3,380
Joined: 19-August 03
From: Auckland, Little Australia


I agree, I would import everyting into a new DB. If that fails, import piece by piece to find offending item (could be a form for example that is corrupted).

--------------------
Beer, natures brain defragging tool.
Go to the top of the page
 
SomekindaVB
post Feb 1 2018, 06:48 PM
Post#8



Posts: 264
Joined: 15-December 16



Thanks Wildbird.

This is exactly what I did in the end. it seems to have resolved. Normally I would rather know why it happens in the first place, so i'm led to believe the actual access architecture causes this problem more than anything I did.
Go to the top of the page
 
GroverParkGeorge
post Feb 1 2018, 08:28 PM
Post#9


UA Admin
Posts: 33,502
Joined: 20-June 02
From: Newcastle, WA


Probably something in the Access architecture combined with the way it is used.

We know, for example, that certain environments and implementations are more prone to corruption than others.

Because it is a file based application, and because it tends to cause more network activity than many other applications, Access is particularly sensitive to the quality of a network and to the way it is configured. Typically, Access databases are deployed in the split configuration, with interface objects in a Front End and tables in a Back End. When the BE is placed on a share on a network, ALL FEs which need to connect to the data in it must do so by sending requests to read and to write data across your network. And because it does so a lot, it generates a lot of traffic. I've heard this described as Access being "chatty". One of the implications of this, of course, is that network quality has a strong influence on both performance and reliability. Bad NICs, failing routers and switches, even loose cable plugs can cause problems. And Wireless for a network which supports Access? Just asking for trouble.

A second problem, fairly rare but not totally unheard of, is forcing users to share a single FE file stored somewhere on a network. It's this usage that can lead to corruption, although one could say that the file based architecture of Access makes it possible to do that. It's another way to encourage eventual corruption.

In your specific situation, the fact that a series of files called "Database.mdb" are being created strongly suggests still a third potential problem.

This has the ring of failed Compact & Repair attempts. The way this process works, at a high level, is this:

a) a new mdb file is created in the same folder as the mdb being C&R'ed. It is called "Database.mdb" at this point.
b) all objects are copied from the original mdb into this new one, leaving behind any previously deleted objects. As you may already know, Access does not physically remove things when you "delete" them. It only marks them that way, and physically leaves them inside the mdb.
c) The original mdb is deleted.
d) the new mdb is renamed from "Database.mdb" to the same name as the original one had.

To us, it looks as if the file shrunk, but it is actually a brand new file.

Now, here's where it can go really wrong. If you try to do a compact & repair when someone else has the mdb open (i.e. trying to C&R a shared BE), Access should just refuse to do it, but maybe it goes off the tracks in the process. If you have made the mistake of sharing an FE, and one user tries to do a C&R on that FE while another user also has it open, there's a much higher likelihood of a corrupting error that leaves behind your "Database.mdb". Now, throw in the option to "Compact & Repair on Close" on such a shared FE and the problem is worse. Every time anyone closes it, it tries to kick of the C&R even though one or more other users still have it open. Bad juju.

I've not personally experienced this problem, but another common way reported to create problems is to try to do a Compact & Repair on an mdb in a network folder. That is, C&R in place on a shared BE, as opposed to bringing the BE to your local computer, doing the C&R, and putting it back. This is often identified as a potential way to corrupt an mdb.

One of the most common signs of such a failed C&R process is the presence of a file called "Database.mdb" in the folder. And now you know where it came from. When you see it next to the "real", original, mdb, you know that a Compact & Repair was tried and it failed. And that's a good time to stop and check for corruption.

Finally, I should note that I've used "mdb" because that's what this post is about, but it all applies equally to accdbs.

--------------------
My Real Name Is George. Grover Park Consulting is where I do business.
How to Ask a Good Question
Beginning SQL Server
Visit My Blog on Facebook
Go to the top of the page
 


Custom Search
RSSSearch   Top   Lo-Fi    22nd September 2018 - 11:53 PM