I have created an Access 2013 db that I need to deploy to several machines, some of which don't have Access installed on them. I can create a .ACCDE file from the .ACCDB file. But when I create a shortcut to the .ACCDE file using VBScript, the shortcut insists on setting the "Opens With" field to "MS Access". Since the .ACCDE file is an executable file, I need it to open directly, not to open up using Access. How can I get the VBScript to set this? Here's what I am using so far.
set objFileSys= CreateObject("Scripting.FileSystemObject")
Set oWS = WScript.CreateObject("WScript.Shell")
If objFileSys.FileExists(oWS.SpecialFolders("Desktop") + "\ClientData.lnk") Then
WScript.Quit
End If
Set oLink = oWS.CreateShortcut(oWS.SpecialFolders("Desktop") + "\ClientData.lnk")
oLink.TargetPath = "C:\Client Data\UnityClients.accde"
oLink.Description = "Client Data"
oLink.WorkingDirectory = "C:\Client Data"
oLink.WindowStyle = 3
oLink.IconLocation = "C:\Client Data\ufsLogo.ico"
REM oLink.OpensWith = ""
oLink.Save
I tried setting the "OpenWith" property, but that's not valid. :-(
I think accde files run on machines without full blown Access still need the Access Run Time...https://www.microsoft.com/en-us/download/details.aspx?id=39358
Related
I have an access VBA script that exports to Excel. It opens the workbook, copies & formats the data and saves the workbook. It's worked for years. It worked on my old system with Office 13, and it works on my new system with Office 16. Now I'm trying to run this on another PC that was just set up - it has Office 13 installed, but may also have the Office 16 version installed that came with the new PC.
When I manually open Excel, Excel 2013 opens as it should. When my Access code runs and tries to open Excel, it seems to be going to the new version - and the code stops working, I think because the Office 16 account isn't set up and when Excel opens it goes to the Office 16 activation screen instead of opening the workbook.
The export macro code is
Public Function Export_data(Optional table As String, Optional opt As String = "")
Set wb_app = CreateObject("Excel.Application")
wb_app.Visible = False
wb_app.displayalerts = False
path = DLookUp("[report folder]", "folder")
If opt <> "" Then
FileName = path & "\" & opt & ".xlsm"
Set wb_obj = wb_app.workbooks.Open(FileName)
End If
The error occurs at "wb_app.workbooks.open" with the error "Unable to get the Open property of the Workbooks class." When I set .Visible to True and look at what Excel is doing, it's going to the activation screen for the Office 16 account.
How can I change the VBA code to direct it to the correct version of Excel?
You can specify the version by using the 2-digit office version at the end of the file, e.g.:
Set wb_app = CreateObject("Excel.Application.14") 'Office 2010
You can look in the registry under HKEY_CLASSES_ROOT to see what's available. Of course, you can query the registry using VBA if you want.
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.
I have a frontend Microsoft Access .mde database that connects to two backends simultaneously. I also give the user the option to link to a sandbox mode backend that resides on their local computer. While I'm developing the frontend, I stay linked to my local version of the sandbox so that I don't mess with the two backends. Sometimes, I want to reset my sandbox to match the data in the backends. The sandbox is a little different in that I combine the two backends together into one. (One of the backends is just log data, so I delete that data after it's in my new sandbox.) I have the process of copying the files and data fairly automated through VBA.
I want to also automate setting the permissions on the new sandbox file after it is copied. The sandbox file should have much more lenient permissions since its data really doesn't matter. I keep getting the error "Object not set." after trying to obtain the Tables collection in VBA in the sandbox file from my developer frontend. I have deduced that I am able to see the Containers and corresponding Documents in the frontend developer file, but I am not able to see them from the frontend developer file when I try to access them programmatically.
I'm assuming that this must be some built-in security feature of Access. Perhaps Microsoft doesn't want to allow a file to modify the security of a different file. Here is some of my code to help you see what I'm doing.
All of these databases utilize the same user-level security .mdw file residing on the server. The database was originally created in Access 2000, but I have since upgraded to Access 2010. However, the I maintain the original Access 2000 file format to be able to utilize the built-in multi-user security.
Public Function CorrectSandbox()
Dim appBackend As Application
Dim appLog As Application
Dim appSandbox As Application
Dim tdf As TableDef
Dim i As Long
Dim doc As DAO.Document
Dim ctr As DAO.Container
'copy the files
mFile.DeleteFile LOCAL_SANDBOX_PATH
mFile.CopyFile PRODUCTION_PATH, LOCAL_SANDBOX_PATH
'copy the log tables
Set appSandbox = OpenSandbox()
Set appLog = OpenLog()
For Each tdf In appLog.CurrentDb().TableDefs
If Left$(tdf.Name, 1) = "_" Then
appSandbox.DoCmd.TransferDatabase acImport, "Microsoft Access", GetAdminPath(eLive), acTable, tdf.Name, tdf.Name, True
'Set permissions for the object accordingly
Set ctr = appSandbox.CurrentDb().Containers!Tables
Set doc = ctr.Documents(tdf.Name) '*** ERROR: Object not set
doc.UserName = "User"
doc.Permissions = 852222
End If
Next tdf
appLog.Quit
appSandbox.Quit
End Function
I'm working with two Access 2010 databases. One is kept on our company file server and the second one is saved locally on several PC's. I would like to store my VBA code in the network database and use that file as a reference library for the local copies. However, with that configuration, the network file is locked for editing as long as the local copy is open. Using VBA, is it possible to break the link between the two files without closing the local file?
In an attempt to find a workaround, I set up a test environment as follows:
Created two blank Access 2010 database files in C:\DB Test\
Local DB.accdb
Network DB.accdb
Added module LocalCode to Local DB.accdb
Added module RemoteCode to Network DB.accdb
Added a reference to Microsoft Visual Basic for Applications Extensibility 5.3 in Local DB.accdb
Added a reference to C:\DB Test\Network DB.accdb in Local DB.accdb
This reference added Network DB to the projects list of my VBA editor as though the file were open.
Added the following procedure to the LocalCode module in Local DB.accdb
Public Sub ClearDBReference()
Dim DBFile As String
Dim Proj As VBIDE.VBProject
Dim Ref As Access.Reference
DBFile = "C:\DB Test\Network DB.accdb"
For Each Ref In Application.References
If Ref.FullPath = DBFile Then
' Successfully removes the library
' reference to the network database
Application.References.Remove Ref
Exit For
End If
Next
For Each Proj In Application.VBE.VBProjects
If Proj.FileName = DBFile Then
' Run-time error '440': Method 'Remove'
' of object '_VBProjects' failed
Application.VBE.VBProjects.Remove Proj
End If
Next
Set Ref = Nothing
Set Proj = Nothing
End Sub
When I executed ClearDBReference, it successully removed the library reference to C:\DB Test\Network DB.accdb but was unable to remove the project for Network DB. It's as though there were a ghost link between the two files but I'm uncertain what is causing it or what to try next.
Not entirely sure I understand your scenario, but it sounds like you're only referring to the Front-End (FE) app/database?
If so, you can create a stub app for local machines, which just copies the FE to the user's machine each time it's run, opens the real FE app, and then the stub app shuts.
That way the 'master' on the server is never locked. Of course, you wouldn't modify this file, you'd work on a dev copy, then replace the master on the server.
ps, the 'master' should be an accde file.
Is there any reason why both DB's can't sit on the server?
A slightly different scenario, but we always put the Front End and Backend on the server with accdb's - that way there's no issues that arrive from network dropouts. Also improves performance and removes the need to backup files on the local PC.
I'm rewriting a legacy access / VBA application in C#. While I am limited as a VBA programmer I am under the impression that the code is minimally compiled and runs almost as a script ? Obviously no security / VBA you can just hit alt + f11 to get at the source code is there a good way to decompile / get at this code?
So I tried this: http://forums.databasejournal.com/showthread.php?t=34222
which appears to be about how to decompile .mdb files.
However the program quickly recompiled itself - or at least says it is recompiling itself in the lower left status bar. Any ideas?
Here are some suggestions (some of which I'm repeating from comments I've made above):
Alt-F11 is not my usual method of opening the VBE, because I usually want to go to the Immediate Windows. Try Ctrl-G, instead.
If both Alt-F11 and Ctrl-G fail to open the VBE, then perhaps the AllowBypassKey property of the database has been changed to False. To get code to change this, search the Access help file for AllowBypassKey (in the VBE, from the help menu, search for "AllowBypassKey"). However, you won't be able to run the code within the database you're trying to investigate if AllowBypassKey is turned OFF, so you can run this code:
//
On Error GoTo Change_Err
Dim db As DAO.Database
Dim prp As Variant
Const conPropNotFoundError = 3270
Set db = DBEngine.OpenDatabase("C:\Databases\MyDatabase.mdb")
db.Properties("AllowBypassProperty") = True
exitRoutine:
If Not (db Is Nothing) Then
db.Close
Set db = Nothing
End If
Exit Sub
errHandler:
If Err = conPropNotFoundError Then ' Property not found.
' do nothing and exit
Resume exitRoutine
End If
Then you should be able to open the database when holding down the SHIFT key (which bypasses any defined startup routines, which might have been shutting off access to the VBE).
If the file is an MDE, there is no source code. You can find out if it's an MDE by checking this property:
?CurrentDB.Properties("MDE")
If it's an MDE (the file can have any extension), this will return "T". If it's not an MDE, it will throw an error (because the property doesn't exist).
Other things to check might be how many modules there are. If you have the database open and can get to the Immediate Windows (Ctrl-G), then this will tell you if there are any modules:
//
?CurrentProject.AllModules.Count
You also might be able to see what's in the database by opening up the Object Browser in the VBE (F2) and selecting the project name in the dropdown at the top (it will say "" by default
Last of all, you may think that it could be protected by Jet ULS, but starting with Access 2000, that's not a big possible, as there's nothing but a password on the VBA project available (i.e., it's no longer covered under Jet ULS). I would expect that if it were password-protected, you'd be prompted for the password somewhere along the line, so you'd already know that.
If it's an .mde you are out of luck. You need to get hold of the .mdb containing the source VBA code that was compiled to create the .mde
HOW TO VIEW SOURCE CODE (.mdb FILE)
Select the file
Hold the 'shift' key
Then double click the file without releasing the 'shift' key
Navigate to the Program Folders on your computer.
Open the MS Office Folder
Navigate to MSAccess.exe and make a shortcut of it.
Move the shortcut to where your database resides (makes life easier and you'll need to do this for each database to decompile).
(optional) Rename the shortcut to something like "decompiler for my database whose name is...." so you know that opening it blows away your compiled code
Right-click on the shortcut to view its properties. In the Target field of the properties dialog box for the shortcut you'll see something like "C:\Program Files\Microsoft Office\Office\MSACCESS.EXE"
In the target field, right-arrow to the end of the pathname, type a space, and then, in quotes, type (or paste) the full pathname of the location of your MS Access file to decompile (easiest way is to copy from the address bar on your window where the file resides, if you have the address bar showing).
Still in the Target field, type a space, and then with no quotes, type /decompile
Click OK to accept the changes and to close the dialog box.
Hold the Shift key down and keep it down.
Wiggle your ears
Double-click on the shortcut.
Go to any module in your database.