I'm having the following issue. I've got a .mde that needs to use another .mde for some functions. That referenced .mde has to be on a unique location for every user. I thought I could drop it on our P:\ drive (which exists for every user but leads to a different folder). The only issue I got there access saves the UNC path and which gets translated to \\[server]\[user]\mylib.mde instead of P:\mylib.mde
So I thought I would use this guide:
http://smsconsulting.spb.ru/shamil_s/topics/testrefs.htm
When I use this it works. Except that I can't close Access without crashing Access.
Some more detailed information about our environment. We're running on Win7 with office 2010 except for Access, which is Access 2003.
Anyone got an idea why this does not work?
EDIT: After some extra testing I've noticed that I Access does not crash when the reference .mde is located on my local hard drive, it only crashes when it's on a network drive.
I have not tested with adding to an an mde only to an mdb, but it may be worth trying this:
Dim ref As Reference
On Error Resume Next
References.AddFromFile "C:\docs\Some.mde"
''Just checking
For Each ref In References
s = s & vbCrLf & "Name: " & ref.Name
Next
Related
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.
Here is my VBA code to be executed in MS Access 2010. For simplicity I've removed error handling in this code. Function resides in a module with a different name.
Public Function ReAddLibrary()
Dim accessProj As Access.Application
Dim chkRef As Access.Reference '
Set accessProj = Access.Application
' Check through the selected references.
For Each chkRef In accessProj.References
' If the reference "MyReference" exists then remove.
If chkRef.Name = "MyReference" Then
accessProj.References.Remove chkRef
Exit For
End If
Next
‘ Add back the reference “MyReference” from specified location.
accessProj.References.AddFromFile "Access Database Path"
End Function
Adapted from
https://msdn.microsoft.com/en-us/library/aa221567(v=office.11).aspx
Premise
Users, use Access databases as the front end, naturally there’s an array of them. One thing in common is that they share reference to an accde database which houses shared functions. Naturally these databases are compiled to stop users getting at the VBA/Design mode. The database that is being referenced is also compiled. Currently work is being done to its accdb equivalent and every time it is published as an accde to the database location, an unresolved reference is created. The reference path hasn’t changed location (Nor will it). All recipient Accdb databases work fine, but their equivalent compiled versions throw a generic error when a button linked-subroutine is clicked for example.
If I use the above code as a subroutine linked to an on click event such as “On Load” for a form housing a button in question, this code works perfectly, even compiled. But if I convert this to a function and link it to a macro named “AutoExec,” it will execute the macro when opening the database but will.
Work in a non-compiled database
Will not work when database is compiled
The AutoExec macro route is because I just want this code pasted in once and executed once when the user opens the database, so the reference is recreated and not broken.
Macro
Action: RunCode
Function Name: ReAddLibrary ()
My thoughts
Initially, I’ve looked into late binding as a solution but I’m finding it hard to grasp as I don’t really code in VBA, I primarily code in sql and thus miss Intellisense and syntax highlighting. All examples are for excel workbooks making it difficult to relate. All my users and myself use the same Access 2010 so there is no version confliction. So I don’t know if this is the answer.
http://www.granite.ab.ca/access/latebinding.htm
I considered running a script to recompile all the user’s databases. But, work to the referenced database is incrementally on going and booting people off would be a nuisance.
Why, when the compiled version still retains the correct accde file
path does it not work, when simply the referenced database has been
recompiled again?
Is it programmatically possible to drop a reference (If it exists)
and add a reference, when a compiled version of Access boots up, such
as linking it to a macro named AutoExec?
Is there an alternative way to run the above code without having to
add it to an ‘Event’ for all form objects? Saving me time as I can
centralize the code in one place.
Any Ideas?
The simple and sad answer is that whenever your code and/or a reference is changed, the project has to be compiled.
So, when done, you have to distribute both the project accde file and its external files (those that are updated, in practice all) to the users.
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.
A week ago, I build a form with a host of buttons to run queries between certain dates in my database, and then export those dates into an excel file. Over the past couple days, I expanded the capability to support custom file locations, sheet names, and source table names. I did all of this so that the tool is useable by whoever comes after me (I'm an intern).
About an hour ago, however, I started getting the error message Run-time error '3275': unexpected error from database driver (1) in a pop-up box. I can't upload pictures directly yet, but here is a picture of the structure of my form. My code is below:
Private Sub SendToExcel_Click()
DoCmd.TransferSpreadsheet acExport, , "TBL_XL_DATA", _
"X:\Confidential\Weekly Intel.xlsx", _ \\The file location is here in the actual code
True, "Input"
End Sub
This is the 'default' export option, which I have not modified in any way over the past few days. The new function is as follows:
Private Sub CustomToExcel_Click()
DoCmd.TransferSpreadsheet acExport, , [Forms]![Date Range]![SourceTable], _
[Forms]![Date Range]![FileDest], _
True, [Forms]![Date Range]![SheetName]
End Sub
I found a similar question, with the same error, and using TransferSpreadsheet, but I don't think my problem is the command running too slowly, expecially considering I ran it (the newer command) an hour ago without trouble.
I am perplexed as to why the command doesn't work now, and why the unchanged command that I haven't dealt with in a while is also now throwing the same error. I am hoping someone understands enough about the error itself to give me a suggestion or two. What should I look for? What should I tinker with to get more information about it?
Found the solution in an obscure forum. My problem is that my path is too long for transferspreadsheet to handle. I am in luck, since my database and excel file are in the same folder. I am sure there is a way to have longer paths be supported, so if anyone knows how to do that, it would be appreciated. For now, I can at least work within the bounds of my constraints.
You haven't supplied the second argument of TransferSpreadsheet which is to specify they type of file that you are exporting to. You should supply this argument explicitly rather than relying on Access to provide it.
DoCmd.TransferSpreadsheet acExport, acSpreadsheetTypeExcel12Xml, etc..
for Excel 2007+ (saving as .xlsx).
You might include in your code a check of the file extension that the user has supplied (if any) so that you can use the corresponding spreadsheet-type enumeration.
The error that you received may have been because a file extension wasn't supplied.
Added TransferSpreadsheet accepts a maximum path-length of 64 characters. I would first attempt something simplistic like storing the fullpath in a variable and passing this variable to the method. This is unlikely to get around the limitation though.
Personally, I would transfer the spreadsheet to the temporary, or current, folder, perhaps:
Application.CurrentProject.Path
Then use a simple FileSystem Statement:
FileCopy source, destination
to copy the file, and finally:
Kill source
to delete the temporary version.
This seems a little long-winded but, personally, I like it. It offers me more control over the process. And it is necessary anyway, to get round the 64 character limit.
This error is also being caused by recent Offices Patches:
see https://www.computerworld.com/article/3233260/microsoft-windows/excel-access-external-db-driver-errors-linked-to-this-month-s-patches.html
and ODBC export to Excel fails under Windows 7, Windows 8.x and Windows 10
Our MS Access 2000 developer left the company a year ago. We need to open his app in design mode in order to make modifications. Double-clicking the .mdb file while holding the shift key doesn't work. When I do that the developer toolbar shows for a split second, then all toolbars go away and the app opens as users would see it. No toolbars show and only a basic dashboard is visible to run the app. I tried using the password recovery tool mentioned here but the tool says there is no password. Can someone tell me how I can open this app to make code modifications?
Beth's answer worked for myself and a co-worker. I've copied the solution here from the link in case the link dies.
"...To unlock the Access DB you can use the following if you know the full path to your database.
Copy the following function into a module in ANOTHER database and call the function. You will need to set the strPath to the path of your database."
Public Function ResetExternalDatabaseBypassKey _
(Optional tfAllow As Boolean = True)
'Name: ResetExternalDatabaseBypassKey (Function)
'Purpose: Sets AllowByPassKey to true in another Access Database
'Author: John Spencer UMBC-CHPDM
'Date: May 02, 2000, 12:08:19 PM
'*******************************************
Dim dbs As Database
Dim strPath As String
On Error GoTo ResetExternalDatabaseBypassKey_ERROR
strPath = "C:/MyDatabases/SomeDataBaseName.mdb"
Set dbs = DBEngine.Workspaces(0).OpenDatabase(strPath)
dbs.Properties("AllowByPassKey") = tfAllow
ResetExternalDatabaseBypassKey_ERROR:
Select Case Err.Number
Case 3270 'Property not found
MsgBox "Allow Bypass Key property does not exist " & _
"for the chosen database."
Case Else
MsgBox Err.Number & ": " & Err.Description
End Select
End Function
Make sure there wasn't another copy left around without this code enabled.
This is typical code used to do this sort of thing, SetByPass There are instructions to hit Cntl-G to open VBA Editor and run code to unset this thing.
Have you tried creating a new blank database, and then importing everything?
It sounds like the shift key by-pass has been set, but that's as noted usually only needed for deployment. In fact, for any access developer, this is quite much a standard approach.
So, it not clear if anything at all been locked up here or the person just set things up as most access applications should be when deployed to users.
About the only thing you lose when importing to another application is the tools startup settings and the shift key. If there are custom menus, make sure you check the option to import those also. (However, be careful, as sometimes custom menus can be setup to run a macro on startup, and this was an old security trick). So, if importing once with tool bars and holding down shift key still causes startup code to run, then try creating another blank database and this time import everything except the menu+tools bars from the old application. Holding down shift key will thus then work for you.
Also, if the system not asking your for a password, then what would you expect a password recovery program to do? All you need is basic access developer skills here to deal with this problem and throwing things like password removal when you not being prompted for passwords will not move you forward here.
On the other hand, if after importing all the forms into a new database the design ability is grayed out, then this was in fact a mde file, and you are in a rather difficult situation unless you can find the original mdb file used to create the mde.