I have having task manager call up a VB Script which opens an access document at a certain time everyday, and when this document opens it has VBA Code set up to export the file as a different file type. I am getting an error back that will not allow this to run in task manager. I am really confused, because this should be a really easy task it really is creating a new access program opening the document, and then quitting access. I know that the VBA Code in the access file is correct, because it works OK when the file is opened. Task manager is simple so I know it has to be something with my VB script being incorrect(formatting maybe?), because I double click it to run an I get an run error. I would just set task manager to open the access file, but it will not quit access so we went this way. Below is the code in my script.
dim accessApp as variant
set accessApp = createObject("Access.Application")
accessApp.OpenCurrentDataBase("File Location")
accessApp.Quit
set accessApp = nothing
I did a few searches online already with little luck. Any help is greatly appreciated.
You cannot use a type in your Dim statements with VBScript:
dim accessApp
set accessApp = createObject("Access.Application")
accessApp.OpenCurrentDataBase("z:\docs\test.accdb")
''For testing purposes, comment out when testing is finished
msgbox accessapp.name
accessApp.Quit
set accessApp = nothing
Related
I am using a form in Access to open other access databases that perform various different queries that publish reports. As the databases I am opening use a multitude of tables, queries, and reports that have nothing to do with each other it would be awkward and time consuming to link to them all and tedious to make changes inside the original database.
I am using Dim appAccess As Access.Application to open each one. It creates a 2nd instance of the new accdb which will not become visible. However, if I go into view code in the original database and then go back to the form it opens the new instance perfectly visible and will continue to do so as long as I keep the original database open. If I close the original database and reopen it I have the same issue which can only be resolved by viewing the code again.
As an example of what I am using
Option Compare Database
Dim APP As Access.Application
Sub TEST()
Set APP = New Access.Application
APP.Visible = True
APP.OpenCurrentDatabase "C:\Users\Documents\Database1.accdb"
End Sub
Does anyone know why this is happening?
Add line:
APP.UserControl = True
For more info review https://www.devhut.net/2018/01/21/ms-access-VBA-open-another-database/#:~:text=MS%20Access%20VBA%20%E2%80%93%20Open%20Another%20Database%201,to%20truly%20appreciate%20the%20power%20of%20automation.%20
How can I use VBA to restart Microsoft Access 2007 from within the same DB file..??
I'm developing a DB that will eventually be packaged & distributed with the Runtime. For development I'm changing various UI settings, and renaming the file back & forth between *.accdb and *.accdr. But I would like to use a fully programmatic method, which I would then assign to a button or keystroke.
But as anyone who's tried can tell you, one cannot easily use VBA to restart Access from within the same DB. I tried the code here: MS Access: how to compact current database in VBA, but I received the error message "You cannot compact the open database by running a macro or Visual Basic code."
I have various half-baked ideas how to "bounce" the restart off a VBS script, CMD file, or another Accdb file, but I wanted to ask who else may have done this successfully..??
What variety of ways have others done this with success..??
I had the following procedure to copy new version of frontend and then open. Unfortunately, had to abandon when IT tightened security and can no longer programmatically copy files. Don't ask me why it works, it was found code. Previously, I had VBA call a VBScript which would do the copy and reopen.
Private Sub Form_Load()
'Check for updates to the program on start up - if values don't match then there is a later version
If Me.tbxVersion <> Me.lblVersion.Caption Then
'because administrator opens the master development copy, only run this for non-administrator users
If DLookup("Permissions", "Users", "UserNetworkID='" & Environ("UserName") & "'") <> "admin" Then
'copy Access file
CreateObject("Scripting.FileSystemObject").CopyFile _
gstrBasePath & "Program\Install\MaterialsDatabase.accdb", "c:\", True
'allow enough time for file to completely copy before opening
Dim Start As Double
Start = Timer
While Timer < Start + 3
DoEvents
Wend
'load new version - SysCmd function gets the Access executable file path
'Shell function requires literal quote marks in the target filename string argument, apostrophe delimiters fail, hence the quadrupled quote marks
Shell SysCmd(acSysCmdAccessDir) & "MSAccess.exe " & """" & CurrentProject.FullName & """", vbNormalFocus
'close current file
DoCmd.Quit
End If Else
'tbxVersion available only to administrator to update version number in Updates table
Me.tbxVersion.Visible = False
Call UserLogin End If
End Sub
I use the utility provided here: http://blog.nkadesign.com/2008/ms-access-restarting-the-database-programmatically/
In a nutshell, when you run this, Access will quit. However, before it quits it will create a small batch file in the same folder as the database with a couple of commands in. Access then quits, and the batch file will then wait for the removal of the lock file (laccdb file). Once that's removed (as it should be if you're the only user in the database), the batch file then restarts the application.
There is also an option to compact the database on close, too. It works incredibly well for me in my environment, and I have successfully used this for probably somewhere in the region of 5 years.
Edit: The answer to this question can be found within the comments of the accepted answer.
I am attempting to open an Access database from a button click within my excel file. I currently have this code:
Private Sub bttnToAccess_Click()
Dim db As Access.Application
Set db = New Access.Application
db.Application.Visible = True
db.OpenCurrentDatabase "C:\Users\wcarrico\Desktop\wcarrico-CapstoneFinalSubmission.accdb"
End Sub
This seems to work briefly and then Access shuts down almost immediately. If it matters, the Access file has an AutoExec macro that runs through a few tests itself on open.
Don't try to open the Access application then; just create a connection object using one of the Data Access technologies:
- OLE-DB or
- ODBC.
Google "ODBC Connection strings" or "OLE-DB Connection Strings" to get details depending on your particular configuration (and Access filetype).
Probably ADODB is the easiest current library to use for your data access.
Update:
Try Importing the data from Access then using the Data -> From Access wizard. Yu can always use the Macro recoding facility to automatically generate some VBA code for you, that will create some infrastructure for you; I use this regularly when exploring new portions of the VBA object model.
Update - Final resolution of problem, from comments below
That may be because the variable goes out of scope; move the declaration of db outside the function, to module level
The code started Access by creating an application instance assigned to an object variable. At the end of the procedure, the variable went out of scope so Access shut down.
You accepted an answer to use a module-level variable for the Access application instance. In that case, Access remains running after the procedure ends. However if the user exits Excel, Access will close down too.
If the goal is to start Access and leave it running until the user decides to close it, just start Access directly without assigning the application instance to an object variable (Set db = New Access.Application). That db variable would be useful if your Excel code needed it for other purposes. However, it's actually only used to open the db file.
You can use the Run method of WScript.Shell to open your db file in an Access session.
Private Sub bttnToAccess_Click()
Const cstrDbFile As String = "C:\Users\wcarrico\Desktop\wcarrico-CapstoneFinalSubmission.accdb"
Dim objShell As Object
Set objShell = CreateObject("WScript.Shell")
objShell.Run cstrDbFile
Set objShell = Nothing
End Sub
I know this is an old thread, but you will get this error in Excel VBA if you are trying to open an Access database, but you do not have two specific References clicked. (Tools, References on the VBA Editor screen). You need to click 'Microsoft Access 15.0 Object Library' and 'Microsoft ActiveX Data Objects 6.1 Library'.
Remove the New declaration then it works
Actually it is pretty straightforward:
Private Sub bttnToAccess_Click()
db = DBEngine.OpenDatabase("C:\Users\wcarrico\Desktop\wcarrico-CapstoneFinalSubmission.accdb")
End Sub
For this to work you need to declare db as Database at the Module level.
Dim db As Database 'Requires reference to the Microsoft
'Access Database Engine Object Library
I'm trying to open a series of Excel spreadsheets using an instance of Excel created inside of a module in an Access database. I can get the files to open properly; however, the actual call to make Excel start takes quite a while, and to open the files takes even longer. The location of the files doesn't matter (same time to open on a local HDD as a network drive).
In an attempt to figure out what was taking so long, I added a timer to the logging module. Opening the files takes approximately 2m30s, during which the host application (Access) is entirely unresponsive to user input); the rest of the script executes in less than 10 seconds.
I'm using the standard Excel.Workbooks.Open call as follows
Set OpenSpreadsheet = Excel.Workbooks.Open(Name, 2, False)
Using Debug.Print methods around this line says it can take up to 2 1/2 minutes for this one line to execute.
Is there anything I can do to make the Excel files open quicker?
EDIT: When opening, UpdateLinks is False and ReadOnly is True; all other options are left to their defaults.
First idea: Can you use a jet driver with an ODBC connection to Excel, instead of opening it in an Excel object? Might be much faster.
Second idea: Make sure to create and instantiate the Excel application object just once at the beginning of the routine, then use the Excel.Workbooks.Open() and Excel.ActiveWorkbook.Close() for each spreadsheet. That way you're not "re-launching" the MS Excel application each time.
To draw out the second of #BradC's well-advised recommendations, if you need to use Excel in more than one procedure, create a self-initializing global function. I always use late binding for automating Office apps.
Public Function Excel(Optional bolCleanup As Boolean = False) As Object
Static objExcel As Object
If bolCleanup Then
If Not objExcel Is Nothing Then
Set objExcel = Nothing
Exit Function
End If
End If
If objExcel Is Nothing Then
Set objExcel = CreateObject("Excel.Application")
End If
Set Excel = objExcel
End Function
Then you can use it in code without needing to initialize it, and the single instance will remain available to any code that needs to use Excel.
And when you shut down your app, you'd call Excel(True) to clean up.
I do this with Outlook and Word all the time. However, there are some COM apps that it works poorly with, such as PDF Creator, which doesn't take kindly to this kind of treatment (you end up in an endless loop with it shutting down and re-initializing itself if you try to destroy the instance this way).
Another approach depends on your setup and process.
In my case I need read-only access to a set of Excel documents stored on SharePoint. My code is currently like:
For each path in paths
set wb = Workbooks.open(path,false)
next
In this case, each workbook is individually downloaded each time a workbook is opened. It would be significantly more efficient if the files were downloaded asyncronously and after the download is complete, the rest of the process executes on the local disk.
My idea is to use CopyFileEx() and pass a callback function. Excel will then download the Excel documents to disk asynchronously and call a VBA function regarding progress. When all files are completed, we can launch the next part of the process, which opens the local workbooks, scans them and then removes them from the local drive.
I'll post code later if I manage to implement it.
This does NOT work:
Sub X()
Dim A As Access.Application
Set A = CreateObject("Access.Application")
'Do Stuff
End Sub
However, this DOES work:
Sub X()
Dim A As Object
Set A = CreateObject("Access.Application")
'Do Stuff
End Sub
I know they do virtually the same thing, but can anyone tell me how to make an access.application object? I should add that I have Crystal Reports 11 and on my last upgrade, it may have 'unregistered' some VBA DLLs.
(Update 2009-06-29)
In response to the first 2 questions, I am using MS Access VBA to control some other Access & Excel files. Since this will only ever run on my local machine, I can guarantee that Access will always be installed. I have also referenced the "Microsoft Access 11.0 Object Library" (MSACC.OLB).
I know there's ways around this, i.e. use early binding when coding, and switch to late binding when running it, I just don't understand why the early binding method doesn't work at all on my machine (Of course, the code works fine on another machine with Access).
If you are writing this in Access there is no need to do that as the Application object is already there for you. If you are writing this in Excel or Word then you need to add a reference to the Access Library. Go to Tools/References and look for Microsoft Access XX Object Library
Hello,The code that you say is not working is legal syntax. What error are you getting? When does it occur? Do you know the line of code it happens at?
Just as a side note, this is legal syntax as well: Dim accApp As Access.Application
Set accApp = New Access.Application
But to be clear, the CreateObject Syntax is legal and not the source of the problem.
Try Detect And Repair from the Help menu in MS Access. Worked perfect for me.