I have an Access Database. When I try to open a report, either in Design view or Regular view, it takes nearly 2 minutes to open. This is a new behavior (everything was fine last week but after leaving my computer, and the DB, on over the weekend, this started) and even occurs when opening a report that has no data bound to it. Not sure if this matters, but the DB is split. This even happens with I try to programmatically open a report, using DoCMD. I've tried to compact and repair both sides, but this does not seem to help. Any ideas?
thanks
jason
Try to change the default printer of Windows.
Access reads the information from this when launching a report.
Related
I have a MS Access database where the user will click a button to open a report. The report appears to be opening (white window for a few seconds; might be doing the query). But then the report just closes. It has happened to 2 users on 2 different reports, but same Database. This does not happen to me. And I'm the programmer of the database.
the "Docmd.OpenReport" is straight forward: open the report as a preview, no criteria.
I thought maybe the form is expecting a certain printer. so I printed with a printer, then deleted that printer. the problem was not replicated.
Anyone experience this? and any solutions?
Not sure if this helps, but I vaguely remember encountering a similar problem, and it was the result of records in the underlying query being locked while the report was being generated for preview. The command button code to open the form had On Error Resume Next; so no error was generated, the query didn’t run (due a record lock issue), and the report would just close with no error.
I have a Access version from yesterday, where everythink works. Today I made a copy of if and changed a label in the report. After saving the report I am not able to open the report agian. I tried to open the report in the navigation, there is a short loadtime and then nothing happens. Also when I use a copy from yesterday and I just save the report without changes, the report doesn't work. When I open the Backup from yesterday without any changes, than I can open the report normaly. The report is based on a temp table which work great for itself. When I create a copy of the working report, than this copy works until I save changes. Than it broken too. I also did some restarts of the pc and nothing changed... I got crazy, does anyone have an idea?
Access can have weird corruption issues sometimes. Try a compact and repair on a copy of your original, working version. Just because it currently works doesn't mean data corruption has not already occurred. If you are lucky the repair will work. If not you will have to recreate your report; mostly by copy/paste but test often so you don't copy whatever corrupt element is there.
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.
I am trying to utilize windows task scheduler to distribute Access reports to End Users in my company.
All I am doing is triggering a macro that runs code from a module which exports a report to a PDF, prints it out, then exits access.
DoCmd.Quit acQuitSaveNone
That's what I've been using at the end of my code in VBA to close access after running a macro.
When I manually run the macro it works fine, but when scheduled on a task, it gets held up a lot and stuck.
I've checked event viewer to try and find any Microsoft Office alerts but do not see any.
It appears that Access is unable to quit many times when running through Task Scheduler. Would there be a VBS I can run, say, 5 minutes after the task to close down the .accdb file and MSACCESS.EXE or is there something I can do to make these Tasks actually work??
It seems maybe when running in the background through task scheduler.. the code is getting ahead of itself and trying to quit at the same instance that it is finishing the output to the printer, causing it to seem "busy" and unable to actually close?
I have an entire domino of code that shoots off after this but it stops dead in its tracks when it cannot finishing closing access.
Any suggestions?
Thanks,
Ian
Here is the gist of what I would do, I am just addressing the print on open and quit actions. You may need to tweak to ensure that you have validation etc in place.
First, make sure that your report has a default printer specified. (Report design-->Page Setup-->Page-->Use Specific Printer and then select your printer)
Create an Autoexec (auto execute) macro, this macro will be saved with the name Autoexec. Macros named Autoexec executes when Access is opened automatically. Note that once you have this macro, it will run each time you open Access, to prevent it from running, hold down the shift key and then open Access, this bypasses the Autoexec
First action in your Autoexec Macro is OpenReport and set the View to Print (report is printed when opened)
Next action in your Autoexec Macro is QuitAccess with options set to SaveAll.
When you run an application from the scheduler, it runs with different credentials. You want to make sure that you choose the appropriate options here.
Fixed it. Very glad as I've seen many with this issue and hope this gets to them.
If anyone has any issues regarding access macros and task scheduler and this doesn't work - I'll be happy to help as best as I can as the frustration of wanting to remove administrative tasks through automation that don't work out is just terrible.
Since I needed the task scheduler to wake the computer up, log me in, and open access databases on network drives that reference SQL servers.. there was a couple things I had to make sure were set up.
First is trusted locations. Any network drives you are access should probably be in the trusted locations.
Secondly, my last command on the macro is DoCmd.RunCommand.Close (I believe.. if im wrong Ill change tomorrow when I'm back in the office)
Third, use the root path to the network folder and not a mapped drive as they may not map when your logged off... so instead U:\file path... would have to be \computer1\filepath\ etc..
This path should be made with all linked tables or databases among the network especially if you have code calling for those files.
Fourth, I ended up having to do it the less preferred way and have a folder called "accessjobs" where I put shortcuts to Access Macros which triggered code and simply ran that path in task scheduler with "start in:" the folder the macro shortcut is in.
Fifth I had to run with highest privileges, and selected "run whether user is logged on or not"
A couple of these things may be coincidental that they work, but I am not about to spend even more time with trial and error to see which settings are benine as I spent TOOO long figuring this all out. But now it is solved and the sky is the limit now!
Thanks for the help!
Ian
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.