What is the deal with Access 2013?

mkaeser

Registered User.
Local time
Today, 13:50
Joined
Apr 14, 2014
Messages
74
Hello All,

I have a database that was built in Access 2010. I have several users that have access 2013 and they are able to use this database just fine. I have switched computers, and I am not trying to open this database in 2013 and it crashes when it tries to open the main/dashboard screen. No error other than the non specific "Access has stopped working". I try to open another version of the same database and still, I have the same problem. This database was working fine in Access 2010, and any other computer with access 2013 is able to open it, so it has to be something to do with this newly installed access 2013 from the 365 Home Suite. When I compact and repair, I am able to open it just fine. But then when I close and open it again, I get the same issue where it crashes upon opening that 1 form. Any thought on what would cause it to work fine in 2010 but bug out in 2013?
 
Different PCs have different drivers and setups. I too have had this, and could not solve it.
Did you try , in the new version, make a new blank db in the old format.
Then import EVERY object from the bad db.
This sometimes fixes it.
 
I have isolated the problem to a specific query. I have NO IDEA why there is an issue with this query, as it is very similar in design to others in the DB. But, when I delete this query and open the database, there is no error.

Now, I have re-created the query and form associated with it. It works fine, until I close the database. Then I get the error again. There is no VBA behind the form, it is just this query that is throwing this error. I feel like I'm losing my mind!!!

All I can think to do it import everything into a new database again, then try to recreate the query. But if that doesn't work, I have no idea what to do.
 
Ok so like I mentioned before, I isolated the issue to a query. I have a login form that opens to a splash screen that contains several different sub forms that show which stage of the process a project is in (being prepped, being analyzed, completed, etc.). This query that is throwing the error shows projects that are currently being analyzed. I fixed this issue by deleting the query and form, exporting everything else to a new database, adding back in all the references needed, and creating the query and form again. So far, it seems like the issue has been fixed. But I really don't understand what happened? There was no VBA behind the form opening, the query was a standard select query selecting projects based on the project status. I have about 5 other queries that do the same exact thing. Even when I deleted the query and form and created new ones in the SAME database, it would work fine until I closed the database and crash when I opened it again.
 
The most common cause of the problem you describe has to do with the way your References are set up. From a Visual Basic window, click Tools >> References and see if any say "Broken" or "Missing." If so, your problem is that the query called something that is in the erroneous reference.

Why? Depending on how they are installed, it is at least in theory possible to have many different DLL and MLB and TLB files (and other file types, too) that are optional. If you take THIS option, you get THIS set of DLLs; if you take THAT option, you get a different set of DLLs. So the first place I would look is broken references.

The second place has to do with the ordering of overlapping references. For instance, if you have both DAO and ADO recordsets, they have similar or in some cases identical entry point names. If you have both references and use both type of recordsets, you need to qualify your variables because whichever one was declared first in the list of references will always be selected. (This is not limited to recordsets, by the way - other object types can run into this. I'm using recordsets as the easy example.) If you want a DAO recordset, when you declare it, you have to qualify it.

Code:
Dim RS1 = DAO.Recordset
Dim RS2 = ADO.Recordset

Finally, if other users can do X AND the database files in question have at least one member on a shared server, check the permissions on the file server and see if there is a firewall or something similar in place that excludes system ABC but lets in systems DEF, XYZ, etc.

I'm sure there are other possibilities but these jump out at me first.
 

Users who are viewing this thread

Back
Top Bottom