So I have a MS Access database at work. Recently I tried to put out another MDE file, that actually took something off a report that was previously there. Now I am getting this error that says, "MS Access cannot create the MDE" with a little show help button....click the show help button and it gives a description about this relating typically to too many objects (Forms, reports, tables, etc). This database is not very big at all, so I am wondering how this could be happening?
Does it count each time I release an MDE with only minor changes, all the same forms, reports, etc over and over again?
Could this be another error and the pop up box is kind of blanket or generic?
Is there anyway to solve this?
Does this count objects on a form/report (text boxes, cmb boxes, etc)?
Basically the example given in the help says that if you have 500 forms, and 2 modules for each form, then that would count as a 1000....this database has about 12 forms, 4 queries, 16 tables (max record = >1000 records) and is not very big. Since the last time I released an MDE with no problem, I have only tried to deleate an item off a report for this new one, without adding anything new.
Please help....there are screaming for this, and I am at my wits end!
Thanks
Yes, this is a misleaidng and blanket error message. Try compiling your code. Ctrl+g >> Debug >> Compile should tell you what line of codes is/are causing your problem.
I would suggest compiling your code on a frequent basis. I do so every few lines of code.
Chances are you had some code in the report referencing the control you removed from the report.
Objects count for the life of the database, that is, even if you delete them, they still count. I suggest you decompile, compact & repair, and then copy everything into a fresh database, which will get you a nice, clean copy. Make sure it compiles and then create your mde.
Related
I can't figure out what is going on with my report in Access 2010. When I run it, all the queries and recordsources are generated and the report shows up, perfectly full of data and formatted in print preview. If I try and print a hard copy or export to PDF, the subreports don't print. I have done compact and repair, closed and opened, and check everything I know, but it's not working. The only thing that I can think of is that the subreports are based on temp tables I generate and set within VBA after I pull all the parameters I need. But I don't see why this would cause it to preview but not print? Any help would be greatly appreciated!!
Here's the solution I found... when I moved the table creation code to the button that prompted the report rather than having it use the openargs in the open event of the subreport, it worked. Don't know why exactly it liked it one place better than the other, but I'm glad that it works now!
After many hours in research and experimentation the only solution was a third party print function: http://www.lebans.com/reporttopdf.htm. Leben’s function always produces a printable PDF with visible subreports.
No modification of the report’s properties was of any value, though this is suggested by various posts; it failed to work for me. Similarly, compact and repair failed to help, as did the creation of a wholly new MDB file and importing all the forms/tables/queries. I ran the MDB in Access 2003 and in Access 2010 on another machine and had the same failure.
This points of course to the issue being embedded within Access. Research shows this has been an issue plaguing Access for many years; in its inimitable lack of care for users getting work done Microsoft has failed to even comment on this, much less fix it.
I had a similar issue and thought that I should post my fix in case someone else runs into the same problem.
I had a report with two subreports on it. From a form, I would select from several combo boxes and then hit the button to run the report. When the report opened (in preview and in report-view) it looked fine, and the subreports worked fine. However, when I tried to print or save, the subreports would not show up.
My solution was in my queries and in the form. The report's source queries were pulling criteria from the combo boxes on the form. Once the report was run, the combo boxes would clear, thus clearing the criteria for the queries. After the report is run, the report looks at the queries again when you try to print/save.
If you have a similar setup, I would suggest checking your source queries again after the report is run to see if you are still getting results. You should see the same data in your queries and in your report. If not, there's where to start looking. Hope this helps anyone else struggling with the same issue.
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.
I have a MS Access 2010 DB with bunch of forms,queries ,macros, Reports etc
The data for my report comes from ODBC links to SQL Server 2000 Tables via linked table property.
Now, whenever i goto design mode of a report,Everything moves painfully slow (I have to wait atleast half a minute for every mouse click,or to select a text box , or any operation performed on the report)
The report itself takes about a minute to run.Which i dont mind.
All I am looking for, is a quicker way to make changes to the design of reports.
This is an old question, but I had a similar issue with form design running extremely slowly recently. For me, only one form seemed to be affected (all others ran fine in design mode). The record source for the form was a complex query built on a hierarchy of subqueries. I dumped the query results into a table and used the table as the record source for the form instead of the query. This appears to have resolved the issue. Hope this helps someone else.
I found the main cause to be the Access conversion program that converted 2003 format to 2010. If you create a new .accdb and then import all of your object, it should work OK. I definitely fixed my issues
What worked for me is based on the answer provided by Albert Kallal at http://www.utteraccess.com/forum/lofiversion/index.php/t1959800.html.
For me, in my split database, if I open any table that is linked to the backend then opening any frontend form or subform was very quick. If I do not have open and keep open a linked table, then it takes about 20 seconds to switch from Form View to Design View and another 20 seconds to open a subform, etc. When I have a linked table open (it does not matter which table, just any table linked to the backend), then it takes about 1 second to do any of those functions. Huge difference!
That is not normal. Something is wrong. Could be your Office/Access installation, your OS installation, something taking up too much of the system CPU, or your system just not having resources, like memory, to properly run Access. Or that your DB is corrupted and/or bloated.
Two tests you can try.
First, do a compact/repair on the DB and see if that fixes it.
Second, is to start your computer in Safe Mode and see if Access still runs slow. This will test for much of the above issues.
What worked for me was to change the subdatasheet name from 'auto' to 'none' on all local tables. Do this in the property sheet in table design mode. There are routines posted elsewhere that will find all your local tables and change this value.
A table was linked to an Excel file. I found that when the Excel file was open, it took forever to change to design view on ANY form. Closing the Excel file eliminated my problem!
My case is access work fine in every function except opening or designing report. But access can work fine when network disconnect. I found it's cause by printer share by other computer and the computer which was removed. I remove the printer from control panel and access can work smoothly.
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!
Has anyone else come across a situation where the contents (SQL statement) of an Access 2003 or 2007 was completely wiped (the Query object still exists, the inner SQL does not)?
Does anyone know what causes this?
I've just had this happen to me again. 2 queries run from a Macro's OutputTo actions to generate 2 Excel files. I ran the Macro a few times then suddenly no more SQL statement in both Queries.
No, I've never seen this happen. And I've read pretty much all the postings in the Usenet and Microsoft newsgroups mentioning corruption for the last ten years or more.
But I'm wondering. Do multiple users share this MDB? We've had a few bizarre postings with respect to Access 2007 losing VBA code.
I have accidently done this in VBA code in MS Access by creating QueryDef object whose name that matched an existing query.
Yup I've had this happen in a 2003 database - I thought perhaps the database had been corrupted so I rebuilt it from scratch this time using Access 2010, but it has just happened to me again. Macro / button has been working as expected for months, but after I changed 1 line of VBA code in a completely unrelated part of the application (setting a field to null instead of ""), this query wiping has started again.
I run a macro triggered from a button which outputs the results of a SELECT to a file. I've worked out the specific steps I can take to trigger the Query being wiped out, however if I check the query still exists in between each step then the query doesn't get wiped! Obviously this is not a solution for the application users.
I have found in another stackoverflow question Weird Bug: "DoCmd.OutputTo acOutputQuery" is deleting the query a work around I am going to try - change the built-in macro ExportWithFormatting to run code instead and restate the SQL before running the output command.