I have the following set up on a server
Two MS-Access queries
Exported the data from the queries and saved the export steps
Created a macro to run these export steps then exit MS-Access
Created a batch file to open ms-access and run the macro
This works fine and dandy if I log into the server and double click the batch file, but if I set up a scheduled task to "run even if not logged in" then the ms-access macro doesn't seem to run....so it seems like access is never ran.
Does anyone have any ideas? Can you do this sort of process when "not logged in"? Is there something else I need to do? I am really stuck and need to have this automated.
Thanks!
My best guess is that you are trying to access a mapped network location that is not available.
Many networks have logon scripts that map network drives to local drive letters. These logon scripts are not run when you set up a scheduled task to "run even if not logged on."
So if you either:
A) are exporting your query results to a file on a mapped network drive (ie, N:\MyExport.txt) or,
B) have one or more tables in the source of your query that are linked to .mdb's on mapped network drives (ie, CurrentDb.Tables("MyTable").Connect = "N:\MyBackend.mdb")
then the process will fail.
If you are expecting to see an error message when you log on, you won't see one because the Access process is not visible when run through a scheduled task. However, if you go to Task Manager you should see an MSACCESS.EXE process listed.
If this is the problem there are two possible workarounds:
Use UNC paths (ie, \\fileserver\folder\MyExport.txt instead of N:\MyExport.txt)
Set up your scheduled task to run a batch file that:
maps the network drives using NET USE commands
opens your MS Access program with the appropriate command line arguments
Related
I created a script that compacts .mdb files on a schedule.
It works great when I call msaccess.exe with the /compact argument, except when it finds an mdb file that has been corrupted.
Instead of compacting it, it stops processing and shows this message until I click OK, and only after that does it start the compacting: microsoft access has detected that this database is in an inconsistent state
How do I avoid this window? Is there a /quiet or /nogui equivalent argument that shows no GUI and just does the compact commmand?
This script would run at night and I can't be there to click OK every time.
JETCOMPACT is not an option, because it freezes when I try to compact one of our mdb files.
There isn't an easy way in terms of a /quiet command switch but various options are described here:
https://answers.microsoft.com/en-us/msoffice/forum/all/is-there-a-way-to-do-a-quiet-command-line-ms/fe22a76e-3e45-4716-884c-1641ef75d3cf
I solved it myself in PowerShell. This compacts and repairs mdb files without confirmation or messageboxes interrupting:
$ObjectAccess = New-Object -ComObject "Access.Application"
$ObjectAccess.CompactRepair($MDBFilePathSource, $MDBFilePathDestination)
$ObjectAccess.Quit()
[System.Runtime.Interopservices.Marshal]::ReleaseComObject($ObjectAccess)
The Problem
I'm using a scheduled task to open an MS Access database, run a macro to email a report in PDF format, and then close the database. The report is relatively basic and the macro simply uses the EmailDatabaseObject action to export & email the report in PDF format.
This has been running successfully on a daily basis for the past 4 years on a Windows 7 machine running the latest version of Office 365 compatible with Windows 7.
I've recently updated the machine to Windows 10 and I'm now encountering a No Current Record error when running the scheduled task. After clicking OK to the error several times, Windows reports that MS Access has stopped working and the application crashes.
If I manually open the database and manually run the macro, everything is successful.
Setup
Windows 10 Pro 20H2 (19042.964) 64-bit
Office 365 Apps for Business 2104 (13929.20296) 32-bit
My Research
I've found this MS KB article describing the issue, however, this reportedly applies to MS Access 2003 & 2007. My report has no grouping, but does contain summations in the report footer. However the suggested solution is not feasible since removing the summations would remove necessary information from the report.
I've found this related question, however, this attributes the cause to accessing the database from OneDrive as opposed to a mapped network drive, whereas I am accessing the database from a mapped network drive.
This looks to be the same issue, but I cannot access the 'solution' at Experts Exchange...
What I've Already Tried
Rolling back Office 365 to an earlier version (version 2101).
Running the Scheduled Task with Highest Privileges - but this results in no access to mapped network drives.
Running the macro from a batch file.
Opening the database from another PC and running the macro from a batch file.
Perform the operations using the AutoExec macro rather than invoking a specific macro by name.
Imported all objects from the database into a new local database.
Exporting the report as a PDF locally using the ExportWithFormatting action.
Using the DoCmd.SendObject method to email the report - this results in MS Access immediately crashing.
Changing the default Windows printer & default report printer to 'Microsoft Print to PDF' to rule out possible printer driver issues.
Current Workaround
I've found that this error only arises when the export format is set to PDF; as such, my current workaround is to export the report to RTF format - but this is obviously not ideal.
Update
I've now systematically removed items from the report until I was able to run the report successfully from the scheduled task.
I removed items until I was left with a single static label in the Report Header and a set of fields in the Report Detail referencing basic numeric & text data from a single table in the database.
Removing the Report Header & Footer resulted in the report running successfully from the scheduled task, and so I determined that the issue must be caused by a setting associated with the Report Header/Footer.
I isolated the issue to the 'Force New Page' setting in the Report Header:
With this set to 'After Section', the report crashes; but if this is set to 'None', the report is successful.
However, when setting this to 'None' in the original report, the report still crashes when run from the Task Scheduler and output to PDF.
Steps to Reproduce the Problem
I've uploaded an incredibly basic database here, containing a single table, a single report, and a single macro which executes the ExportWithFormatting action followed by the QuitAccess action.
To reproduce the problem, open a command prompt window and issue the following commands:
cd C:\Program Files (x86)\Microsoft Office\root\Office16
msaccess.exe C:\YourPath\test.accdb /x macro1
MS Access should then open and you may be presented with the 'No Current Record' error.
Has anyone else encountered this issue and knows of a solution?
Many thanks for your time.
I would like to know if there is an easy workaround for my following question. I have an access database that have different modules in vba (and of course each module with different subroutines). How can I do to create an icon or an executable file that by clicking on it it runs one of the subroutines of one of the modules without opening access?
The reason of this is because when I am away people need to run some of these subroutines and these users don't have any experience with Access.
You can start Access with a command line option to run a named Access macro. (That means an Access macro object. Some people also call VBA procedures macros, but an Access macro object is different.)
An Access macro has a RunCode method which you can use to run a VBA function. Since the code you want to run is a subroutine, create a new function which calls that subroutine and shuts down Access afterward, and use the function with the macro's RunCode method.
After you have the macro working correctly, test it from a Windows Command Prompt session following this pattern:
"<path to MSACCESS.EXE>" "<path to db file>" -X <macro name>
After working out those details, you can create a desktop shortcut to do the same thing.
However, if your Access operation must be run by you or another user on a regularly scheduled basis (daily, weekdays only, etc.), you could create a Windows Scheduled Task to do it and forget about other users and desktop shortcuts.
Note this suggestion isn't exactly what you requested because it does open Access. But it could close Access after the operation is finished, so perhaps it will be acceptable.
I need to run a MS Access job as an automated task. I know Access isn't really built for this type of task, but I have MOST of it working except for one, critical part. In short, this is what it's supposed to do:
Generate a PDF report for a user
Generate an email for the user
Attach the PDF to the email
Send the email via SMTP
It works if a user is logged into a desktop session. The process needs to run as an automated process, without requiring a user to be logged in. Using Powershell and the built-in Task Scheduler (Windows 7 Ultimate, 64-bit), I'm able to get it running on schedule. But the Access code fails when it tries to save the PDF. Through experimentation, I learned that I need to save to the "My Documents" folder, and I have the process running as "me", but I keep getting the same error message:
8/18/2014 4:00:17 PM Report Error in <method name>
2302
-1
0
<project name> can't save the output data to the file you've selected.
MTS
So I suspect that if I select the correct location to save the PDF, it will work. Is there a special location that the system and/or Task Scheduler (TS) can save to? Is there a special way to share a folder that it will allow TS to write to it (without requiring a user to be logged in)?
I personally usually save all these types of files/reports into the %TEMP% folder, which seems appropriate for this application since it is only to store it until it is emailed.
I haven't had any permission issues saving into this folder yet.
If you're unfamiliar with %TEMP% you can search for Environ variables and there are usually different useful file paths to common folders used by the system e.g. %APPDATA%,%USERPROFILE%` etc
Thanks for all the input. After exhaustive testing--based on the response from ashareef above--I've demonstrated that it can't be done. I tried saving to the following environment variable locations:
TEMP
APPDATA
LOCALAPPDATA
PUBLIC
USERPROFILE
I also tried:
C:\Users
C:\Temp
C:\Users\<my user name>\Documents
And none of those worked if I set the task to run whether I was logged in or not:
One location does work, but only if I'm logged in and I set the task to run only when I'm logged in:
C:\Users\<my user name>\Documents
To sum up:
Saving a file from Access
Running as a Scheduled Task
Whether you're logged in or not
Is not possible! So here at work, we're going with Plan B. Thanks for your help!
I am new to MS Access. I am building a simple project and I already have created the tables, forms and queries. My question is, how would I compile and run my program ? Is there "F5-like" to run my project on MS Access ? Or how am I going to do this? Thank you.
In other Microsoft environments, F5 is the shortcut key for "Start Debugging", or "Run", or words to that effect. When the application starts it performs a default action:
Windows forms-based applications will display the startup form
Windows console applications will start running at static void Main()
ASP.NET applications will display the default page (Default.aspx).
Unfortunately, while the VBA development environment does have an F5 shortcut key to run code (and it can be very handy during development), it doesn't mean the same thing as it does in the other environments listed above.
To "run your project" in Access you need to manually perform whatever action you have specified as the default action when the database is opened. That is normally one of two things:
If you have created a Macro named AutoExec then Access will run that, or
If you have specified a startup form (see screenshot below) then Access will open it.
So, to launch your Access project simply open the startup Form or run the AutoExec Macro. (Or, you could always just close the database and re-open it, and let Access perform the default action for you.)
make sure you have ODBC access support to run your program