So currently my boss and I are the two employees that work on our company's access database. I just got Office 2013 on my computer and he is will working with 2010. We have ran into some inexplicable bugs with the database.
Most of these can be fixed by just copying an old version of a form or report into the database when it fails; however, it is quite disconcerting when we spend hours trying to discover why something is wrong and are able to fix it without explaining why.
Most of the issues so far have occurred when I am using the db in Access 2013. So far the issues have been:
Access occasionally crashes and restarts when I am working in the VB code
Some forms bug out for no reason. It yet again occurs when I am working in the VB code if there is a compile erro. To further explain the "bugging out", the form usually contains about 2000 separate forms that you can search through, but when it bugs out it will only show one blank form. At first I panicked thinking all the table's data was gone, but nothing changed the table
There have been other hiccups, but nothing noteworthy besides these two
I guess my question is if anyone else has had issues along these lines, or if they knew of any other known issues. I tried to research errors people have been having, but I couldn't find anything besides Microsoft's official release of what features were being deleted.
As always, thanks in advance!
Your system should be split into two files. FE(front end) containing all forms, queries, code, etc., linked to the BE. BE(back end) containing the data tables only.
Maintain a development copy of the FE that is only used for making modifications.
Each user should have their own copy of the FE on their local machine. If you don't know how to split, just search for it as there are plenty of instructions out there.
I have 2010, but I worked with a consultant who worked on the same project in 2013. I too, saw some behavior that looked like version related bugs, but nothing definite.
Responding to your list:
Access occasionally crashes and restarts when I am working in the VB code -- This has happened to me in every version of Access I have used, from 97 to 2010.
Some forms bug out for no reason. It yet again occurs when I am working in the VB code if there is a compile error... -- If the compile error is severe enough to lose project state, this is not surprising.
Recommendations:
Decompile your application front-end occasionally, especially when 'weird' errors show up. See this SO link: automating decompile / recompile in ms-access
Compact & Repair at least daily while developing your application
Backup! Do this at least for every significant revision. Sometimes, the Access front-end will become so corrupt that it trashes all of your work. When this happens, nothing is recoverable.
Related
I have an Access, 2007 – 2016, accdb database on my Toshiba Satellite Pro running Windows 7 32 bit. I am using MS Office 365.
The database that opens at its home page, but any attempt to open a table, form or module brings up this message:
“The database cannot be opened because the VBA project contained in it cannot be read…”
I have 2 backups of this database, but they do the same thing.
I have read several posts on the internet that indicate that the problem can be solved by decompiling the database.
I have tried the VBS Script solution contained in:
How does one decompile and recompile a database application?
However, it does not get to decompile as the same message displays when the .vbs file opens the database.
I have read some other posts that indicate a problem with a VBA7 file, but these refer to Access 2010, so I do not know if they also apply to me. I have VBA7.1 by the way.
Attempts to decompile through the Command Prompt has its own problems that seem to be associated with file names with spaces.
So, I’m stuck. Any help would be much appreciated
I ran into this same error at work, Have you tried shift-clicking and opening? I know that seems obvious, What I did, was I got the DB open in safe mode, and opened up a module in the vba editor, and tried to fight the problematic code, if anything you could delete all your modules after copying them into a notepad.
I also right clicked and restored previous versions from windows, I am not sure if you have tried this when you say you have to back ups, but i was unaware of this fix and i luckily had a version from last week that fixed my issue.
I have a problem with a DB I started work on a couple of years ago in Access 2010. I fired it up last week and now I'm getting an "unrecognized database format" error when I try and open the front end.
I left this project sat after the company lost interest in finishing it. Since then I worked on another project on the same dev machine which required me to install Access 2007. I had both 2010 and 2007 installed at the same time and I remember opening the now problematic db to take some snippets from some code in there for use in the other project. Im pretty sure I only opened it in 2010 at that time.
Now the company has shown interest again I need to finish the project.
Ive tried uninstalling all instances of Office and the Access Database Engine (I needed this to test the 2007 project) running a clean up and putting a fresh install of 2010 back, but Im still getting the same error. Ive tried importing the objects from the accdb file into a new db but access still throws the unrecognized database format error. The same error is given if I try to decompile as well.
Today Ive tried uninstalling office 2010 and putting a clean 2007 install to see if I can open/decompile/import from the older db under that version of access but Im faced with the same error.
The file server where I backed up to has been rebuilt since I worked on the original project and I thought that the accdb file might have been corrupted during this process as Im pulling it from the old vhd. I've also pulled backups from several locations and all the files give me the same error. Ive even tried running them on one of the clients where I know it used to work and has not been had office tampered with since I was last looking at this and still I get the same error. I know that I had compact and repair on exit set on the front end and Im wondering if I managed to inadvertently use 2007 and the last time I opened it and royally screwed it up unknowingly creating a little surprise for me here two years down the track!
I have even tried installing an "Access Recovery Toolbox" util to see what that could make of the file, and it pulls absolutely nothing back in the report.
I have a much older version of the db which works on my dev machine but Im at a massive loss if I have to start work from this version as I made some very significant changes between these versions including changes to the back end table structure.
Any light anyone can shine, even if it just means getting the VBA out into a text file would be really helpful!!
TIA
Have you tried creating a new DB and pulling in the tables, forms, etc from the bad DB? I would recommend doing it incrementally and checking the new DB after each import. IE just bring in the tables and then see if they are healthy before moving on.
OK so this is kind of a general question here. We run an ASP/C# Site that's fed by a SQL 2008 R2 database.
Our data entry takes place using Microsoft Access 2007 and feeds to a SQL 2008 R2 instance.
Our data entry forms (all .adp) are generally simple, but we randomly run into problems where I'll post a change to the DB (we have a script that runs at night and will archive our old DB versions in the form of "DB_NAME.adp03122012" and keeps the newest revision as "DB_NAME.adp". This way, our data entry team will just need to click on a network shortcut to access the Access forms.
What we're running into is non-reproducible errors of varying types on random machines.
Example, I make a simple search that has a combo box and a search button. You select the item you want to search for and it updates the record source to search for that PK/FK. It works fine on my developer box. It works fine on certain end-user boxes. But on others, it throws a run-time error:
"Run-time error 2467: The expression you entered refers to an object
that is closed or doesn't exist".
Now the error itself isn't the focus of this. It's not being able to reproduce it. I tried running it on another box that has the same hardware specs as the offending box and it ran fine, no errors, no nothing.
I'm at an absolute loss as to why this is happening. I don't think the error is actually related to my VB code or to our databases, as it's working fine on some computers and isn't working on others. It's almost as if the code isn't propagating properly to specific boxes.
Has anybody else dealt with this before?
I feel somewhat foolish, but our Network Admin hadn't propagated Windows updates to all of our end user boxes.
The advice that Remou and mwolfe02 gave was valid and helpful, and likely would've helped had I been informed that the computers in question needed updates.
Thank you for reading and offering comments and help.
Last week I was modifying portions of two modules in an access 2010 db when the program crashed, and would crash every time I tried opening up the db thereafter. I was able to create a new database and import the tables and queries from the corrupted one, but when I tried to import the forms/macros/modules the new database would start crashing also. I keep daily backups, but ended up losing several hours worth of work. This happened twice last week, each time MS Access would crash without warning and the VBA was unrecoverable.
The functionality works as intended until the db crashes seemingly at some unknown point. There must be some sort of issue with my VBA code, since this only started happening when I started modifying the module last week, but I can't pinpoint it since the crashes actually occurred when nothing was being executed. Ie during save.
Does anyone know if it's possible to export the VBA out of access without exporting it to another database? Ie export it without having to use MS Access to do so. On a related note, has anyone created a library that exports query definitions, table schema, and all VBA to text files that I could drop them into source control?
Thanks.
In addition to the method suggested by #Remou, you could try the SaveAsText method to save a code module to a text file.
Application.SaveAsText acModule, "Module1", "D:\Access\Module1.txt"
However, that doesn't satisfy your desire to do it without using Access.
Try a decompile operation on the chance your project includes saved compiled code which has been corrupted. You can find detailed instructions for decompile in the 2 answers to this Stack Overflow question: ms-access: HOW TO decompile and recompile
After decompile, make sure all your modules include Option Explicit in their Declarations sections. Check the project's references, and fix any that are broken (missing). Then run Debug->Compile from the VB editor's main menu to verify your code compiles without error.
Those steps are the best I can offer to reduce potential for continued corruption problems.
For integrating source control with Access, start with this selection of related Stack Overflow threads: site:stackoverflow.com ms-access version control
Folks
We're having the same problem. There is a bug in SP1 that causes it. If you keep opening the database, you'll finally end up with a backup that works - rename the old one BROKEN and remove the _backup from the new database, and you are oky till your next bit of development. Our IT guys (Microsoft Gold Partners) are looking at a fix reported on http://answers.microsoft.com/en-us/office/forum/office_2010-access/access-2010-sp1-you-receive-random-crashes-in/d2bf6175-075a-4a12-a2b1-f55d40af271b
I may go take a look at decompile/recompile however as some of our database have come all the way up from Access 97, to 2000, 2003 and now as mdb/2003 file format still, running under 2010. Having said that, converting to accdb/2007 seems even worse!
I have an interesting issue with TFS reports. When I run the QUERY: Team Queries->Planning and Tracking->Work Breakdown, I see the correct information, which is to say that I see the work items, etc. that are entered into TFS. However, when I run the REPORT: Reports->Project Management->Requirements Overview I see that same data PLUS data that is no longer in the system.
Important information:
* I am using TFS 2010
* When I originally created this project, I used a Microsoft Project plan to upload the work items. Before my team started using it, I decided to forget about Project and just use the web/studio interface, so I used the query "Delete all items" to clean the database.
While the clean worked in all other cases, this report seems to be holding on to those items, and I would like to know if there is a way to fix that. It has been several weeks, and I ran the cube reports to see if it was updating (everything updates fine).
Anyone have a clue what's going on here?
I'm not familiar with the query that you talk about, but if you do a delete of workitems, the delete may not have been propagated to your warehouse (and subsequently the cube). If you have a relatively small number of WorkItems in your TFSWorkItemTracking database, it may be a good idea to rebuild your TFSWarehouse, which will then refresh your cube.
Take a look at the SetupWarehouse.exe command, which should be installed on your Application Tier. This could take anywhere from an hour to a day to run, depending on your version control and work item tracking database, so you may want to do it off hours. It shouldn't affect the day-to-day execution of TFS, just the reports.
The above is for TFS 2008 Only. Per Matthew below, here's the answer for TFS 2010
From what I found SetupWarehouse.exe
no longer exists with TFS2010. In the
Administration Console, under
Application Tier->Reporting, there is
an option called "Start Rebuild".
Using this completely resolved my
problem. Thank you. It should be noted
that there is NO feedback from
clicking on "Start Rebuild". At first
it looked like the admin panel hung,
then it came back without feedback. It
took about an hour for reports to
start working again, which is the only
way I knew it was done.
If you ever get into the situation again where you need to permanently get rid of one or more workitems, you should get the TFS Power Tools. The TFPT utility has a "destroywi" command that allows you to permanently (and safely) remove workitems from TFS.
Power Tools are available here: http://msdn.microsoft.com/en-us/vstudio/bb980963