All
I have a database which exports to a word document (via a report saved as an excel document). Essentially access exports the report, opens it and word, and then parses the data into a word table. There are a handful of reasons it's done this way, rather than just exporting the report directly to word, and it all works fine.
Until...
We have worksite / filesite integration, and so if you are not connected to the local network, worksite prompts you during word startup for the relevant document server, or ask if you want to operate offline, or operate locally. The problem I have is that because all of the word document creation isn't visible (and I'd prefer for it not to be), there's no way of answering this prompt.
We can resolve this by just saying "if you're not connected to the network, you need to open an instance of word before you try exporting." But that's annoying, and also people just forget, with the result that the export just hangs (there's no error to handle), and you have to manually end the word (and excel) processes though task manager.
Is there a way to e.g.,
Run a timer in parallel, which is set going just before the create.object("Word Application") line, and when it gets to a certain point (say 20 seconds) and the code hasn't advanced, then it just assumes something's gone wrong and makes word visible?
Or to detect the presence of the filesite dialog?
Or, ideally, just provide the input for the dialog programatically (i.e. "click" the Local button)(the user is prompted for an export location, which is always local)?
Related
I have an Access file which I wanted to change the design of. I did not create this file. However, when I open the file it immediately opens the switchboard form. I cannot see the side panel that I see normally containing Access objects like: tables, queries, forms, reports etc. Is this just a run time version where I cannot see other objects or is there a way for me to access other objects?
I have learnt about run time version but I had never seen it before so I am not sure what this is.
I have built my application but a problem has arisen that I cant get my head around - My application has no autoexec yet so I open access and double click on my userform to open it.
On opening the userform Access crashes and closes
However, if I first put the userform in design view, then open the form in form view it works fine.
How can this be?
It cant be the Form Load coding or it would still crash when going from design view to form view.
I will include my form load coding in case:
Me.LastImport.Value = DLast("LastImport", "tbl_Import_Export_logger")
Me.Text42.Value = Date
Me.Text44.Value = Date - Weekday(Date, 3)
'Compliance Reporting
Me.Text68 = DCount("[CustomerAccountNumber]", "Q_HealthChecksOverdue") 'Overdue Health Checks
Me.Text76 = DCount("[CustomerAccountNumber]", "Q_HealthChecksdue") ' Due Health Checks
Me.Text74 = DCount("[CustomerAccountNumber]", "Q_HealthChecksCompleted") ' Completed Health Checks
Me.Text72 = DCount("[LettersDueStatus]", "Q_LettersSent_Query") 'Count number of letters sent
(originally written on Stack Overflow Documentation)
How to troubleshoot Access crashes
When you receive an error: "Microsoft Access has encountered a problem and needs to close", there is often not a lot of information to help you identify the cause of the error. Below are a series of steps you can take to troubleshoot the cause of the errors.
Decompile Database
This should always be your initial fix. A good policy is to decompile the database before each release.
Create a decompile shortcut.
This loads the database with a "/decompile" switch.
Right Click your Database File. Select Copy
Right Click in the explorer window and select "Paste Shortcut"
Right Click the shortcut and select "Properties"
In the Target box, go to the end of the line and add /decompile
Click Ok to close the shortcut
Open Database with Shift.
Hold down the shift key while double clicking on this shortcut.
This prevents any auto runs from executing within the database.
You should go straight to the navigation window.
Compact and Repair the database.
Once the database is loaded, you will need to click the Compact and Repair button.
Locate the Compact and Repair Database button on the Tools Ribbon.
Hold down the Shift Key. Keep holding it down while you click the Compact and Repair button.
Recompile the Database
Go into the VBA window (Control + G)
Select Debug -> Compile from the menu
This is the complete decompile process. Generally it should fix 99% of all Access crashes or weird form behaviour.
Rebuild the entire database
This is a lot of work, so do this as a last resort after exhausting all other options. You only need to do this if the problem is occurring for different users, on different machines. If it isn't occurring for all users, then most likely it is not a corrupt database container.
Similar to the steps in removing binary data, you are going to rebuild your database from scratch. This process is a little ritualistic, but if done meticulously with care not to "preserve" any possible corruption, then the process is highly effective.
Create a new access database container.
In Access, on the File Tab, you can select "New". Create a new, empty database in ACCDB format.
Move all objects to the new container
Do not use the Import / Export functions within Access to move the objects, and do not simply click and drag. Doing this can copy the corrupt items over to the new container.
Tables:
For each table in the old access container, create a new table in the new container.
From design view, copy/paste the field definitions.
Check the table properties to ensure they match in both databases
Move any Data Macros over as well (see the Macros section for how to do this)
To move the data, export the old data to XML or CSV, and then import from that format.
Queries:
Load each query into SQL view.
Copy / Paste the SQL text.
Paste into the new database.
Compare Query properties to ensure they match.
Forms / Reports:
For each Form / Report, use the Application.SaveAsText function to export the forms/reports to a text file.
Remove the Binary Data (see Remove Binary Data from Form documentation to acquaint yourself with this process)
Use the Application.LoadFromText function to reimport the objects into the new database
Macros
You have three methods of moving the Macros.
Recreate each macro by hand in the new database container.
Use the Application.SaveAsText / Application.LoadFromText method with the acMacro parameter.
Copy/Paste Macro definitions for each macro
Select All (Control + A) to select all macro elements. Then Copy (Control + C).
Open a blank Notepad document and Paste (Control + V) the Macro XML.
Create a new blank macro in the new database container.
In Notepad, Select All text (Control + A). Then Copy (Control + C)
In the blank macro, Paste (Control + V). The Macro should appear. Save it.
Modules
For each module, select all code (Control + A) and paste (Control + V) into the new database container.
Be sure to check the Database Properties (In VBA Window, go Tools -> Client Properties)
Data Macros
For each Data Macro, use the SaveAsText / LoadFromText methods.
Go into the VBA Immediate Window (Control + G)
Type Application.SaveAsText acTableDataMacro, "MyTableName", CurrentProject.Path & "\MyTableName.txt" (Replace MyTableName with the name of the table containing the data macros)
Review the file for any signs of corruption
In the new database container, load the definition using Application.LoadFromText acTableDataMacro, "MyTableName", CurrentProject.Path & "\MyTableName.txt"
As previously mentioned, this is a LOT of work, but it has results. This method should also be used when migrating an Access 97 database to 2000, or an Access 2000 database to 2003.
Remove "OLE Object" fields
If you have images or other data stored in Access itself as OLE Objects, then you should find a better approach. When the OLE data is stored, it is stored according to the software (and version of software) on the computer storing it. When another computer goes to display that OLE Object data on the form, but doesn't have the exact software / version installed - quite often this results in an application crash.
If you are storing image data, then a better approach is to store the filename, and instead save the images to a standard location. Newer versions of access have the native controls to make this the way to go.
Remove Binary Data from Form
Sometimes the crashes occur constantly in a single form or report, or occur only when printing. It is possible that the binary data within the form / report has become corrupt.
Save the Form / Report object as text
There are two undocumented functions. Application.SaveAsText and Application.LoadFromText. You can use these functions to export the form/report definitions, clean up the definition, and then import it again.
Make a backup of your database before proceeding
Go to the VBA Immediate Window (Control + G)
Type Application.SaveAsText acForm, "MyForm", CurrentProject.Path & "\MyForm.txt" (Replace MyForm with the name of the Form / Report. Use acReport if it is a corrupt report you are fixing)
Rename the original form item (e.g. rename to MyForm.Bak) within the Database Window
Clean up the Form / Report Definitions file
Open the exported file (e.g. MyForm.txt) in notepad
Delete the "Checksum=" line (should be on line 3)
Clear out binary data
Identify the binary data blocks. Look through the file and you will see lines that start with "Parameter = Begin". Following those lines you will have lines of encoded binary data. Finally, the binary block will end with a line consisting only of "End". The Binary Data block includes the first line (with the Begin statement) and all lines up to and including the last line (with the End Statement).
Note: All of these blocks should appear BEFORE your form control definitions
Delete the binary data blocks for the following parameters:
NameMap
PrtMip
PrtDevMode
PrtDevNames
PrtDevModeW
PrtDevNamesW
Look for other issues. While you have the file open, scroll through the rest of the file and look for anything that catches your eye, especially in the VBA module code at the bottom. You will be looking for anything that sticks out from the rest, and may be corruption.
Save the file.
Load the form / report back into Access and Test
Load the form back into Access.
In Access, go to the immediate window (Control + G)
Type Application.LoadFromText acForm, "MyForm", CurrentProject.Path & "\MyForm.txt"
Decompile / Compact Repair / Recompile (See the other example within the documentation)
Open the form / report to test. Hopefully everything is working now.
Delete the old corrupt form (e.g. MyForm.bak)
Prevent this corruption in the future
The most common cause of corrupt binary data within a report / form is when multiple computers / users use the same database client file instead of having their own separate copy. This is why each user should have their own client file on their desktop that they run.
Test Computer Memory
If your crashes are random or sporadic, then do this step. If your crashes occur every single time you run the database, then this step won't fix the issue (although bad memory may be the reason why the corruption occurred in the first place).
Use a memory tester that boots outside the operating system and runs multiple passes. Two popular choices are MemTest86 (Commercial) and MemTest86+ (Open Source)
Start the test and let it run during working hours. The reason for this is because other factors in the building such as noise on the power circuits can cause memory errors, so you want to try to keep the variables the same.
If you have memory errors, then you will need to identify whether it is due to bad memory in the computer, or some other factor. This is beyond the scope of this document however.
Remarks
Be sure to remove other variables from the equation while testing
Network Corruption
Do not load the client off of a network. Put it on the local drive and run it from there.
Corporate Builds
If you are in a corporate environment that is using "computer builds" and have had no success with Decompiling, Testing Memory, nor stripping Binary data - then refuse to do further testing until the IT team can provide the user with a test machine that has only Windows, Office, and Service Packs installed.
All software and updates should be installed by hand without using unattended installs. Do not install antivirus on this machine for testing.
Understand that many IT departments simply try to do a One-Size-Fits-All approach with the builds, and their builds are all based on one another. Over time, software conflicts can directly cause Access to crash or act strange.
Bad Power
As mentioned in the memory example - power fluctuations can cause computer errors. If the database is in an industrial building, then try to get your hands on a power conditioner or a UPS that provides clean power (off the battery, not off the main passing through a Metal-oxide Varistor)
Also, check the power supply cable that is plugging into the power bar or outlet. Make sure that the gauge and voltage specs are sufficient. IT departments often leave power cables plugged in at the station and just remove the machine. After many years, they are using beefier power supplies, but haven't switched out the cable. It makes a difference. When in doubt, bring a new, thicker cable.
Thank you for all the replies. I didn't end up testing the suggestions you all mentioned.
In my case, in VB I ran debug and it highlighted 2 issues in my code so I sorted them, now it runs fine.
Thanks everyone
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
Right now I'm working on an application in access 2010 that generates letters based of data taken from a share point site. The user inputs some parameters from some combo boxes on a form. After the selection is made the user selects the type of letter they want by pressing a button.
This works fine but I'm experiencing an odd issue when I close access and reopen it later.
When I open the form after starting access again I'll attempt to create a letter but instead of working like it did before the criteria prompt window appears asking for a parameter instead of taking the form values.
This happens every-time I restart access and the way I've been fixing it is by changing the names of the combo-boxes and then adjusting the queries accordingly.
This is what i was using to get the form values in the query
Like [Forms]![Main Menu]![A] & "*" (A is the name of the combo box, I got tired of renaming it)
Any Idea whats going on because I'm at a loss.
Thanks in advance!
If you are 100% positive that Access is finding your parameters just fine, and when Access closes they are lost, then:
Do you have any backup copies of this database before the error
occurred? Can you use one of them?
Do you Compact & Repair the database every time you close it? This
can be used somewhat as "damage control," because MS Access does
have a tendency to become corrupt.
Make sure the Main Menu form is open as long as the query is
running. Does it close right away (aka the query isn't finding the
parameter because the form is closed)?
From searching around, it seems that you aren't the only person with this problem. A known fix for people seems to have been copying all objects into a new database (which to me, sounds like the database is corrupt.) This could also mean maybe only your form is corrupt. Perhaps try to create a new form that does all of the same things that your Main Menu form does.
I'm sorry there doesn't seem to be a 'clear-cut' definitive solution for your situation.
If any VBA is involved, see below:
If you use the "Database Documenter" feature and check "yes" to all the options, you will obtain an exhaustive report that should let you trap your problem parameter. Export this report as an .rtf or .pdf document, so it is searchable. Identify a keyword from the dialog prompt, and search on that.
Once you check the query objects using the Documenter, check your VBA code. You'll do this by stepping through code in the IDE. If the main form has subforms, they are opened with (within) the main form. And they load before the main form.
Identify those subforms.
Sprinkle breakpoints in their code modules (if you find a Load function, that is highly relevant).
If the main form has a code module, do the same there.
From this thread
I have an application that creates an Jet database at run-time, and imports ~100k records so that I can make use of the indexing for performance reasons (1 minute versus nearly 10 when not using a Jet database).
The database is created using ADO Extensibility in Excel, and everything works just fine. However, my issue comes whenever I then open the MDB file in Access front-end, it automatically starts to "repair" the database.
The data is still fine after the "repair", however my main output query can not then be viewed in Access as it tells me it cannot represent the joins, and if I then view it in SQL the required joins are not there, and the query can no longer run. This still happens if I let it get "repaired" but do not open that query, i.e. it is the "repair" that breaks the query, not the act of trying to view it in Access. The funny thing about this is that I used the Access GUI query designer to construct the SQL as my life is too short to worry about it's crazy bracketing style, but it then later decides that it's too complex for itself??
Also, nothing else appears to be affected so I can only assume it's this one query it doesn't like.
This isn't a deal-breaker for me as my fix is to make the MDB hidden and advise users who can see it not to open it.
However, I would really like it if the database could be opened and I didn't have to hide it away like that. Therefore, my question is whether there is any way to prevent the MDB being "repaired" automatically?
Thanks!
Microsoft Access is "repairing" the file when opened because it is missing some tables that are specific to the Microsoft Access user interface. Since you created the MDB file directly using OLEDB with Microsoft.ACE.OLEDB.12.0, these tables are not present, and must be created when Access opens the MDB the first time. There are several ways you can circumvent this:
1) Name the MDB something other than .mdb - e.g.: MyAccessDatabase.mad - this will prevent Windows from using Microsoft Access to open the file.
2) Use COM+ to open an instance of Microsoft Access, and have it create the .MDB file. This .MDB file will then have all the necessary tables present and will not need to repair the file.
FYI, whenever Microsoft Access opens an MDB that needs repairing in this fashion, it will inspect all the QueryDef objects for invalid SQL and correct them as necessary. This is why your "complex" query is breaking.