I want to check wheather my database application is running in a fullversion MS Access or only with a viewer / limited MS Access.
The problem is that in a limited version a user can close the last form and then is not able to reopen any form without restart the whole application.
Private Sub Form_Unload(Cancel As Integer)
If LimitedVersion Then
Cancel = True
End If
End Sub
So the question is how to determine LimitedVersion ?
You can use:
SysCmd(acSysCmdRuntime)
It will return True for the runtime version.
However, I would never allow the last menu to be closed in an application. The people with a full version can open the application in a different way if they need access to design.
To simulate the runtime environment, you can use the /runtime switch:
For MS Access 2010, it would look something like this, note that the line break is for display purposes.
"C:\Program Files\Microsoft Office\Office14\MSACCESS.EXE"
"z:\docs\demo.accdb" /runtime
Related
The Problem
I'm using a scheduled task to open an MS Access database, run a macro to email a report in PDF format, and then close the database. The report is relatively basic and the macro simply uses the EmailDatabaseObject action to export & email the report in PDF format.
This has been running successfully on a daily basis for the past 4 years on a Windows 7 machine running the latest version of Office 365 compatible with Windows 7.
I've recently updated the machine to Windows 10 and I'm now encountering a No Current Record error when running the scheduled task. After clicking OK to the error several times, Windows reports that MS Access has stopped working and the application crashes.
If I manually open the database and manually run the macro, everything is successful.
Setup
Windows 10 Pro 20H2 (19042.964) 64-bit
Office 365 Apps for Business 2104 (13929.20296) 32-bit
My Research
I've found this MS KB article describing the issue, however, this reportedly applies to MS Access 2003 & 2007. My report has no grouping, but does contain summations in the report footer. However the suggested solution is not feasible since removing the summations would remove necessary information from the report.
I've found this related question, however, this attributes the cause to accessing the database from OneDrive as opposed to a mapped network drive, whereas I am accessing the database from a mapped network drive.
This looks to be the same issue, but I cannot access the 'solution' at Experts Exchange...
What I've Already Tried
Rolling back Office 365 to an earlier version (version 2101).
Running the Scheduled Task with Highest Privileges - but this results in no access to mapped network drives.
Running the macro from a batch file.
Opening the database from another PC and running the macro from a batch file.
Perform the operations using the AutoExec macro rather than invoking a specific macro by name.
Imported all objects from the database into a new local database.
Exporting the report as a PDF locally using the ExportWithFormatting action.
Using the DoCmd.SendObject method to email the report - this results in MS Access immediately crashing.
Changing the default Windows printer & default report printer to 'Microsoft Print to PDF' to rule out possible printer driver issues.
Current Workaround
I've found that this error only arises when the export format is set to PDF; as such, my current workaround is to export the report to RTF format - but this is obviously not ideal.
Update
I've now systematically removed items from the report until I was able to run the report successfully from the scheduled task.
I removed items until I was left with a single static label in the Report Header and a set of fields in the Report Detail referencing basic numeric & text data from a single table in the database.
Removing the Report Header & Footer resulted in the report running successfully from the scheduled task, and so I determined that the issue must be caused by a setting associated with the Report Header/Footer.
I isolated the issue to the 'Force New Page' setting in the Report Header:
With this set to 'After Section', the report crashes; but if this is set to 'None', the report is successful.
However, when setting this to 'None' in the original report, the report still crashes when run from the Task Scheduler and output to PDF.
Steps to Reproduce the Problem
I've uploaded an incredibly basic database here, containing a single table, a single report, and a single macro which executes the ExportWithFormatting action followed by the QuitAccess action.
To reproduce the problem, open a command prompt window and issue the following commands:
cd C:\Program Files (x86)\Microsoft Office\root\Office16
msaccess.exe C:\YourPath\test.accdb /x macro1
MS Access should then open and you may be presented with the 'No Current Record' error.
Has anyone else encountered this issue and knows of a solution?
Many thanks for your time.
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
Hi I have an application created in Access 2007, it's front-end and back-end is split. I am trying to open the database using Access 2010 runtime, however the application crashes when I change selected item of a combo box.
I receive the following error:
"Execution of this application has stopped due to a run-time error. The application can't continue and will be shut down."
After researching the problem, a few people mentioned running the compact and repair, and found that fixed their problem, however it made no difference to mine.
However, I found most people to come back and say put some error logging in place. So I have done that, and when running on 2010 runtime, a receive a pop up message saying the following:
Error number: 2185, You can't reference a property or method for a control unless the control has the focus.
However when running in Access 2007, there is no error and the code works fine.
This is the code I have been using:
Private Sub ComboBox1_Change()
If Not ComboBox1.Text = "" Then
ComboBox1.Dropdown
End If
End Sub
My question is, why would this suddenly become an issue running on 2010 runtime, when there is no error in Access 2007?
change If Not ComboBox1.Text = "" Then to If Not ComboBox1 = "" Then
For whatever reason Access does not like you use the .Text property outside of it's strict control.
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.
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.