I've been working on this database for a while. I have a development file on my PC and periodically I copy it, split the copy and set up the back end on a network path to test it 'in the wild'.
I've done this process several times, including relinking the tables on the front end after encrypting the back end with no problems. The back end would be encrypted and not accessible without a password and the front end connected to the back end as expected once it has been re linked using and the password supplied using the 'External Data > Access' tab (This is access 2013).
Today something's changed. I've written some queries and the DB's first report and decided to update the 'demo' version I have deployed on the network. I attempted the exact same procedure as usual (copy dev file, split the database, delete the links on the front end, exclusive open the back end, encrypt, re open the front end with the bypass key, re link, supply password).
However I couldn't re open the front end after encrypting the back end. I've spent the last couple of hours poking at the problem and found that no matter what I can't open the front end when the back end is encrypted. It doesn't matter if I have the linked tables present in the object navigator or not- the front end simply won't open if there's a password on the back end.
The rest of the database behaves as normal and throws out runtime errors when it can't find a table, but somehow even without the linked tables the front end 'knows' the back end is encrypted and will not open while it stays as such.
I've even tried splitting the database, deleting all the links and then reopening the front end. It opened fine but of course wouldn't work without the linked tables. I then encrypted the back end and attempted to re open the front end to add the links- no joy. I then decrypted the back end again just to see what would happen- back to square one with the front end now opening again.
Anyone know how I've screwed this up? Might it be related to the new queries and/or report?
As far as I can tell network permissions have not changed. If I don't encrypt the back end then I can still use the split front end and back end over the network.
Many thanks,
I didn't see that one but I did eventually find this: stackoverflow.com/questions/47419086/… I didn't have to delete any tables but I did have to reveal the system tables (and probably the custom ribbon table specifically). Once I'd done that and gone through the split process everything worked. For the record, the front not opening was literally that. No error message, no runtime errors, clicking the file simply caused access to open on its homepage. – Evis03 Jan 3 at 10:13
Related
I am new to Microsoft Access but have been learning as I go this past week. But now I am stuck. I am writing VBA code that checks if the user is using a current database version from their desktop compared to the database version on the server. I have established a table in the back end that holds the numerical value for each user's version and then a table that also stores the numerical value for the newest version on the server(changed by an admin when changes are made). The current code compares the values to determine if the copy that was opened is the newest version. If it is not it opens the version that is on the server and then changes the user's version in the back end table. But I want to change the copy on the desktop so the next time the user opens the copy it is the new version since the code will identify that the version was "updated".
I know that there is the My.Computer.FileSystem.CopyFile() that can be used to copy one file to a new location and write over the file that is there, but if I use this will it be able to write over the file that is open and running the code that is generating the .CopyFile() command? I already have the version on the server being accessed before the .CopyFile() command, but I just don't know if it will actually execute. I'm also not sure if I like the fact that the user will need to reenter their user name and password once the server version opens. Does anyone know of a way to overwrite the file on the desktop without the user even knowing?
I have already done that in a previous database and with some modifications I think you can make it suitable to your needs.
I will start from the point that you have checked the version and found if it is the newest available or an old one.
If Not updated Then
Select Case MsgBox("An update is available for your client!!!" _
+ " You would be able to use this client version but without new features and support!" _
+ " Do you want to update now?", vbYesNo Or vbInformation Or vbDefaultButton1, "Available Update")
Case vbYes
'Call MsgBox("Please contact your administrator to receive your new client version!!!", vbExclamation Or vbDefaultButton1, "Available Update")
Shell "cmd /c ""<whatever path you want>\doupdate.cmd"", vbHide" 'calls a cmd script to do the dirty job of copy -> see below
Application.CloseCurrentDatabase 'closes the current database
Exit Sub
Case vbNo
<whatever you want on no>
End Select
End If
You can remove the select on the above code and it will run everytime the variable updated is False without asking the user.
The cmd script code is the following:
#Echo OFF
SLEEP 3
copy "\\server\groups\<whatever path>\file.accde" "%userprofile%\Desktop\file.accde" /Y
call "%userprofile%\Desktop\file.accde"
exit
The above script is surely not perfect because of a 3sec busy waiting on the begining, but I want to be sure that access has time to close. (The problem will be big enough if acccess hangs on close.
What you can also do is to add the above or the command My.Computer.FileSystem.CopyFile() on the close event of your database, however in that case the update will happen after the user has completed his work with the old version.
Note that in that case I wanted the script that updates to be separate from the database for other reasons. The main principle is the same even if you use vba for the update, you have to close the file before overwriting it.
I am using Access 2007 on a PC running Windows Vista.
The Access database with VBA code in many modules works as expected. However, one module acts differently after I have exited the database and re-entered. As soon as I re-enter, I can select View Code and Save without changing any code and the program goes back to working the way I expected. Any ideas?
Details:
The Access module with the inconsistency opens Word 2007 and creates a new document from a template (.dotx) file using bookmarks to merge Access data into the document. This works as designed without a problem and works every time. Once the document is created, the vba code calls the Word window to front. This does not happen unless I select View Code and Save. I do not have to modify any code, just select Save. Then it works as expected until I close the database. When I next open the database and select the button that creates the Word document, the document is not brought to front but remains behind the Access window. If I select View Code and Save, the subsequent documents created during that session come to front as desired. This is consistent and repeatable.
I am not sure about why this is occurring, but a quick fix that I thought might work would be to programmatically save the module when you load your DB.
docmd.save acmodule, "module name"
Hope this works!
I'm trying to input some code that hides "Design View" as an option for our internal application unless a certain permission requirement is met.
The following code works with one exception:
On Error Resume Next
If Not GetUserInfo("ADMIN_PERMIS") = 1 Then
Dim cb As CommandBar
Dim cbCtl As CommandBarControl
For Each cb In CommandBars
If cb.type = msoBarTypePopup Then
For Each cbCtl In cb.Controls
If cbCtl.Caption = "&Design View" Then
cbCtl.enabled = True
cbCtl.visible = False
Else
cbCtl.visible = True
End If
Next
End If
Next
Set cb = Nothing: Set cbCtl = Nothing
End If
The one problem with this is that it disables Design View not only for the current database, but also for any other access database that is launched. I'm looking for a way to try and apply this code in such a way that it only affects the Access database I have the code in and not in every single instance of it.
I recommend converting the database into a compiled, executable only .accde file (File --> Save & Publish --> Make ACCDE). Doing this will prevent any design or code changes in the application. Keep a development version in the normal .accdb format. Make your changes there and then compile into the .accde version for each update.
Since your team updates the database often, you could benefit from using Peter De Baets' database starter. The database starter makes a local copy of the front end of the database, allowing uses to continue to work while design changes are being made. After the production accde front end file is updated, the users will automatically copy the new file the next time they open the database. In my office I have found that I can push out a quick fix and simply email everyone saying "Close and reopen the database guys!".
All these answers are great. If you are interested in the simplest method, I found the form holds the key, albeit in a strange spot.
In the forms properties->Other Tab->Shortcut Menu =No
I have an access database that is saved in a network location so that any of the 600 employees who work at the company can access the database. When they open the main form it runs a make-table query. However there is a popup from MS Access stating "You are about to run a make-table query that will modify data in your table. Do you want to continue?"
The form will not run correctly if they do not press yes so I want to suppress this prompt so that it does not ask them. I changed the settings from the Options>Edit/Find>Confirm menu so that it doesn't show this confirmation. However, this is apparently a local setting so to enforce this every user would have to change those settings.
Is there any other possible solution to suppress the confirmation message?
There is so much wrong here, I hardly know where to start:
you can't possible have an Access database used by 600 people.
if more than one person opens it and runs the MakeTable, it will break, because you'd be making a structural change that collides between the two users.
turning off error notification is a HUGE MISTAKE. You don't know exactly which errors you might end up ignoring.
turning off SetWarnings means that you can get inconsistent updates from a SQL DML statement, and then you have no way to know which data was updated or not.
MakeTable queries do not belong in any production application. Instead, create a persistent table, and clean it out and append new records to it. But it doesn't belong in your main application -- this is the very definition of temporary data, since it's constantly being replaced, so it needs to be in a separate temp database.
you'd likely want all users to have their own temp databases so there are no collisions if more than one opens the app at a time.
Yes, from VBA:
DoCmd.ShowWarnings False ' Don't show warning popup
DoCmd.RunQuery "MyMakeTableQuery" ' Run the make table query silently
DoCmd.ShowWarnings True ' Turn warnings back on
Use DoCmd.SetWarnings False to stop the message box from popping up. Be warned, however, that this action is global to the Access application. You have to re-enable warnings with DoCmd.SetWarnings True as needed.
You can also try:
Application.SetOption "Confirm Action Queries", False
If you don't already, you may want to have a hidden form open every time the database is opened. You can use the OnOpen event of that form to run startup code like the above.
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.