Can not open database
- Thread starter Gismo
- Start date
Minty
AWF VIP
- Local time
- Today, 04:34
- Joined
- Jul 26, 2013
- Messages
- 10,647
It's corrupt.
Either reload a recent backup or after taking a copy try compact and repairing it. If that fails you may be able to import all the objects into a new blank database.
Unrelated to your issue - but I have to say having recently switched to Access 2016 from 2010 I am getting a lot more corruption style errors occurring. It's really slowing me down.
Either reload a recent backup or after taking a copy try compact and repairing it. If that fails you may be able to import all the objects into a new blank database.
Unrelated to your issue - but I have to say having recently switched to Access 2016 from 2010 I am getting a lot more corruption style errors occurring. It's really slowing me down.
isladogs
MVP / VIP
- Local time
- Today, 04:34
- Joined
- Jan 14, 2017
- Messages
- 18,827
As I always do in these cases, I recommend you first make a copy of your database then DECOMPILE it to remove any corrupt compile code. It almost always works whereas in my experience compacting almost always fails.
For more info see http://www.fmsinc.com/MicrosoftAccess/Performance/Decompile.asp
Try this before creating a new copy of the database. It's quick and easy
For more info see http://www.fmsinc.com/MicrosoftAccess/Performance/Decompile.asp
Try this before creating a new copy of the database. It's quick and easy
Ranman256
Well-known member
- Local time
- Yesterday, 23:34
- Joined
- Apr 9, 2015
- Messages
- 4,354
in that users pc, start access, make a new db,
import evertyhing from your version.
see if that works.
if so, save your version, start using their version, continue editing from that.
i too notice that inserting newer code from 2016 , into an older mdb, will cause problems with older Access.
that $#%@, me.Isdirty , is one.
import evertyhing from your version.
see if that works.
if so, save your version, start using their version, continue editing from that.
i too notice that inserting newer code from 2016 , into an older mdb, will cause problems with older Access.
that $#%@, me.Isdirty , is one.
- Local time
- Yesterday, 22:34
- Joined
- Feb 28, 2001
- Messages
- 30,160
When you try to open the DB in question, is it set up to auto-launch an Opening Form ??
Yes it opens the switchboard
Yes I decompiled the DB but did not work so I created a new DB and imported all objects. it worked just fine but then I got the error on no data report. I decompiled again and when I tried to compile after that, it indicated a corrupt DB and could not even sign in.
I believe "on no data" event has been the culprit in corrupting my DB
after decompiling and repair, all my no data event reports has been cleared of the code. Can this be true and why would access see this as an error and removing the code with decompile? I have quite a few reports using this function, or is there another way of getting around not printing a report if no data is available?
after decompiling and repair, all my no data event reports has been cleared of the code. Can this be true and why would access see this as an error and removing the code with decompile? I have quite a few reports using this function, or is there another way of getting around not printing a report if no data is available?
- Local time
- Yesterday, 22:34
- Joined
- Feb 28, 2001
- Messages
- 30,160
In theory, you cannot execute code that would corrupt your database unless you are somehow touching some of the MSysx tables or if you somehow diddle with the definition collections (TableDefs/AllTables, QueryDefs/AllQueries, etc.). Or performing some other type of skullduggery that should not occur in a production database.
That is because a corrupt database is corrupt at a metadata level. A database having no data is NOT corrupt - it is just empty. Your message capture in the first post is not data-related. There is something wrong with the project itself.
There are no functions of which I am aware that can touch the metadata without touching the hidden system tables to do it (but see the bottom of this post). Having said that you can't do it, it is possible that you might somehow start something in the main flow of some form or report and then have something go off with a timer on the launcher form that would force an application event that would somehow interrupt the process at a bad time and lead to corruption.
I won't say that a "No Data" event can absolutely never corrupt a database - but the code would have to diddle with Access infrastructure to do it. You would know if you had done something like that.
As to the question of not printing a report if no data can be found, I usually built my reports in two stages. First, based on user selections, I created a WHERE clause that would only show the users what they requested. I would tack that onto a SELECT...FROM... string that was constant per report. Since I had the WHERE clause handy, the code that launched the report first tested for whether a DCOUNT based on the given criteria would return any number other than zero. If I got back zero, I never executed the second step, which was to reset the report's .Recordsource and then open the report in the appropriate mode.
Now - here's a shot in the dark. I wouldn't be surprised to find out that you don't have a situation like this because it is a type of "Damn the torpedos, full speed ahead" program style that is not good for production code. You would actually have to work at it to do this sort of thing.
It is at least theoretically possible to call a function or sub in which you have one or more arguments passed by reference that should have been passed by value - and then pass a bad value. This is unlikely for a pure Access function that you wrote yourself, but I could imagine it for something called from an external library where the declaration was not quite right. IF you issue this bad type of call and IF warnings are turned off at the time and IF you have an On Error Resume Next in effect at the time, you COULD theoretically screw the program stack to tears, or you could hit random elements in the object code of the compiled modules, which are actually some sort of BLOB (binary large object) in a compiled database.
Since you believe this error was associated with the "No Data" event, it should be possible to narrow down your search. However, if you have the above situation anywhere in your code, you could leave a mess behind and then the "No Data" event could trip over the mess. But removing the "No Data" event simply means something else has the opportunity to trip later.
That is because a corrupt database is corrupt at a metadata level. A database having no data is NOT corrupt - it is just empty. Your message capture in the first post is not data-related. There is something wrong with the project itself.
There are no functions of which I am aware that can touch the metadata without touching the hidden system tables to do it (but see the bottom of this post). Having said that you can't do it, it is possible that you might somehow start something in the main flow of some form or report and then have something go off with a timer on the launcher form that would force an application event that would somehow interrupt the process at a bad time and lead to corruption.
I won't say that a "No Data" event can absolutely never corrupt a database - but the code would have to diddle with Access infrastructure to do it. You would know if you had done something like that.
As to the question of not printing a report if no data can be found, I usually built my reports in two stages. First, based on user selections, I created a WHERE clause that would only show the users what they requested. I would tack that onto a SELECT...FROM... string that was constant per report. Since I had the WHERE clause handy, the code that launched the report first tested for whether a DCOUNT based on the given criteria would return any number other than zero. If I got back zero, I never executed the second step, which was to reset the report's .Recordsource and then open the report in the appropriate mode.
Now - here's a shot in the dark. I wouldn't be surprised to find out that you don't have a situation like this because it is a type of "Damn the torpedos, full speed ahead" program style that is not good for production code. You would actually have to work at it to do this sort of thing.
It is at least theoretically possible to call a function or sub in which you have one or more arguments passed by reference that should have been passed by value - and then pass a bad value. This is unlikely for a pure Access function that you wrote yourself, but I could imagine it for something called from an external library where the declaration was not quite right. IF you issue this bad type of call and IF warnings are turned off at the time and IF you have an On Error Resume Next in effect at the time, you COULD theoretically screw the program stack to tears, or you could hit random elements in the object code of the compiled modules, which are actually some sort of BLOB (binary large object) in a compiled database.
Since you believe this error was associated with the "No Data" event, it should be possible to narrow down your search. However, if you have the above situation anywhere in your code, you could leave a mess behind and then the "No Data" event could trip over the mess. But removing the "No Data" event simply means something else has the opportunity to trip later.
- Local time
- Yesterday, 23:34
- Joined
- Feb 19, 2002
- Messages
- 47,060
I have found that occasionally, opening the database with a different version of Access will clear up the corruption. I discovered this in the A2003-A2007 period. Ar work we were developing with A2003 and I had an .mdb that would corrupt on a daily basis. When I discovered that I could usually open the database with A2007, I started bringing my laptop to the office.
Also, because of this database, I developed some code that exports all objects (except tables) to text prior to closing the app. That way, if the database could not be opened once it was closed (this was the usual scenario), I could at least rebuild it and not loose all the changes I'd made.
Also, because of this database, I developed some code that exports all objects (except tables) to text prior to closing the app. That way, if the database could not be opened once it was closed (this was the usual scenario), I could at least rebuild it and not loose all the changes I'd made.
