is it possible to run a sub or function as soon as the user opens an access database file? if so, how?
Create your function:
Public Function DoSomething()
' do stuff '
End Function
Then create a macro with the run code action which calls your DoSomething function. Name the macro autoexec. Then, every time the data base starts up, it will run your autoexec macro.
Another thing you can do is set a form to open whenever the database starts. You could then call your DoSomething function from a form event (on open, or on load).
Choose one of those approaches. Either way, if you ever want to start the database without DoSomething running, hold down the shift key as the database opens to bypass your automatic startup routine.
You could open a hidden form on start up like in Access 2007 Startup.
This is also possible in older Access version.
You may use this hidden form for logging or other 'system'-related tasks.
Related
Having this strange behaviour in my Access DB since today. If I try to run code in VBA (i.e. F5) a box comes up and asked to select a macro to run. Never had this problem before as I just want it to run the code I did. Tried to find a solution but no success.
I happens for all my code... like Public Function or Private Sub...
For example I created this code. When I execute it by clicking the button it works but if I run in VBA with F5 it always asks for the macro...
Public Sub Command18_Click()
MsgBox ("Hello")
End Sub
This occurs if you try to hit f5 and run code in a form.
While you can hit f5 for a regular plain jane code in a code module, if you try this for form code, then f5 will pop that macro prompt.
Also, if by accident (or by intent) created a class module? Then again, you see that prompt.
So, for a form code module, or a class code module?
Such code can be started by hitting f5, since you need to create an "instance" of that class before it can be run.
And, a form's code module also is considered a class module - an instance (in this case the form has to be open) must be created first. So, in the case of form's code module, you can set break-point in that code to debug, but you can't hit f5 in such code modules, or inside of class modules - since an "instance" of that object has to be created first, and hitting f5 is not able nor capable of knowing which or even where such code exists to create the instance of that class code module (of which even form's code modules are also this case).
The HUGE giveaway here is that in your comments you note some click() event. Well, then that means your working with code inside of a form's code module - and f5 can't be used to start such code - it is still a class module, and an instance of that code module has to be created first.
So, if I create a class code module like this:
then
Option Compare Database
Option Explicit
Sub TestMsg()
MsgBox "hello"
End Sub
Now, if I hit f5 in above sub, the macro prompt appears!!!!
I would have to create a plain jane regular code module, and say type in this:
Sub TestFun55()
Dim MyClass As New Class1
MyClass.TestMsg
End Sub
So, I can hit f5 in above.
And the SAME goes for code inside of a form's module. You can't hit f5 in that form's code module (which is considered a class code module).
In my database (Access 2013, .accdw), I am checking the user's current version in the Form_Open event. If it is not up to date it triggers an external command to download a fresh copy and then is supposed to close itself to allow for the update. The problem is that after Application.Quit is triggered, access closes but instantly reopens, blocking the download. I've stripped out all the code I can to isolate the problem.
If 1 = 1 Then
Application.Quit
End If
Simplified pretty far, right? It should always just close as soon as the form is opened. With this as the only code in my Form_Open event which is the only code in the form, it still closes, reopens, and then closes again. Docmd.Quit has the same effect. I've tried too many variations to enumerate. In a button this code works fine, but I need it to run the check before it loads any data (the linked tables may be being altered while we change versions).
Any ideas how to make it stay closed the first time it closes?
I think it reopens because your external code (.bat file ?) reopens it. It's not an Access problem. Have you checked the numerous tools you can find for Access automated client deployment ? Here are the first 2 I found:
http://www.databasejournal.com/features/msaccess/article.php/3286111/Automatically-Deploy-a-New-Access-Client.htm
http://www.devhut.net/2015/06/30/ms-access-deploying-your-database-front-end-to-your-users/
Your code works for me in a Form_Open(), but then this is Access 2010 and no Sharepoint.
You may have better luck by Creating an AutoExec macro that calls an initialization function that does the version check, instead of having a form open automatically.
If the version check is ok, then open your start form from the function.
The easy work-around is to always fetch the current version and then launch it.
This way there's no fuzz and the user always run the latest version.
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 am seeking comments on how to schedule auto updates of a database (.accdb) since I am not very comfortable with the process I have set up.
Currently, it works as follow:
Task Scheduler calls a .bat
.bat calls a .vbs
.vbs opens the database and calls a macro
The macro calls a function (VBA Level)
The function calls the update Subroutine
I consider there are too many steps and the fact that it requires 2 external files (.Bat and .vbs) related to the database and stored on the system increase the risk that the procedure would break.
Apparently (but please tell me that I am wrong and how I can change it) .vbs cannot call a subroutine but only a macro. Identically, an access macro cannot call a subroutine but only a function if the user is expecting to enter the VB environment of the database. This is the reason why I called a function (VBA Level) that then calls the subroutine.
Hope some of you know how to shorten the steps and eventually get ride of the .bat and .vbs
To the best of my knowledge the shortest path for a Windows Scheduled Task to "do something useful in Access VBA" is:
Create a Public Function (not Sub) in the database. For example:
Option Compare Database
Option Explicit
Public Function WriteToTable1()
Dim cdb As DAO.Database
Set cdb = CurrentDb
cdb.Execute "INSERT INTO Table1 (textCol) VALUES ('sched test')", dbFailOnError
Set cdb = Nothing
Application.Quit
End Function
Create a Macro in the database to invoke the function:
Create a Windows Scheduled Task to invoke MSACCESS.EXE with the appropriate parameters
In the above dialog box the values are:
Program/script:
"C:\Program Files\Microsoft Office\Office14\MSACCESS.EXE"
Add arguments (optional):
C:\Users\Public\schedTest.accdb /x DoSomething
A VBS script can call any standard VBA SUBROUTINE with the following:
dim accessApp
set accessApp = createObject("Access.Application")
accessApp.OpenCurrentDataBase("C:\MyApp\MultiSelect.mdb")
accessApp.Run "TimeUpDate"
accessApp.Quit
set accessApp = nothing
Note that the sub TimeUpDate is a standard VBA subroutine. This means no Autoexec macros, and no macros at all - only pure VBA sub calls + this VBS script.
There is a little known trick dating back to the earliest years of access to allow it to run as a process which still works. Access will always on startup look for a macro called "Autoexec". If it finds it it will immediately start executing this macro. I find this is extremely useful if I need to initialise the program before opening forms or, as in the case of the original questioner, run access as a scheduled process with no user I/O.
After beating my head against the wall for about four hours, I finally got this to work:
1) Create a DOS batch file with one line it. The line is composed of three parts a) the full path to Microsoft Access (msaccess.exe), b) the full path of the Microsoft Access database with the code in it, and c) the Access command line argument "/x MacroName". The first two items should be surrounded with quotes. Mine looks like this:
"C:\Program Files (x86)\Microsoft Office\Office14\MSACCESS.EXE" "C:\MyPrograms\ProdDB Reports\ProdDB Reports.accdb" /X DailyTestReportsRun
2) Create a macro inside of Access with the name you used in your batch file. It has one command, RunCode, with an argument of the name of a VBA function you want to call. This should be followed by open/close parenthesis "()". I didn't try passing any parameters to the function; I think this would be problematic.
4) Make sure the VBA function you call has a Docmd.Quit command at the end, or that you add this as a second line to your macro. These will make sure that Access doesn't stay open after your process runs.
5) In Windows Task Scheduler, select "create a basic task" (which invokes a wizard). Set the program name to the name of your DOS batch file. There's a helpful check box labeled something like "Open the properties window when I'm finished." Check that so you that go to the properties window.
6) Set the task to run regardless of whether the user is logged on or not. Also check on the "Run with highest privileges" box, which one friend on here suggested.
You can now test everything by right-clicking the scheduled task and selecting the Run command.
I liked Albert Kallal's script and tried it. Everything worked great until I tried to schedule it. Then, for some mysterious reason the scheduler would not kick it off.
none of the above work
ms access DB with task scheduler will not work as to open the db run code and quit the application
the solution I found is to avoid task scheduler and have the ms access db open all time and have a timer in msaccess do the job
In Access 2003, there are ways of running code when a form or database is opened, but what about when the database is closed?
My motivation is the unavoidable use of a somewhat buggy third-party COM library. Releasing the COM reference (by setting the variable to Nothing) causes it (correctly) to disconnect from its server. The trouble is it can't then re-connect without exiting the process and starting a new one (which is a known bug). In this case, the process is the whole Access IDE :(
Ideally I'd like to store the COM reference somewhere that would be protected from the VBA "Reset" action which clears global variables (and is common during debugging, sometimes forced by a code edit). But then I would like to have the chance to clean up before the database is closed.
You could run code at database close if you have a form which you set to automatically open at database startup ... and leave the form open. Then you can use the form's On Close event to run your cleanup code:
Private Sub Form_Close()
'do your stuff here '
End Sub
don't release the reference. Let Access do that when it closes.