I set a form "frmMain" to automatically display when the database is opened by naming it in: Access Options, Current Database, Display Form: frmMain.
In a lapse of judgement of enormous proportion, I included the statement me.requery at the beginning of the class object module Form_frmMain's Private Sub Form_Current() routine.
Now, whenever the database opens, it starts requerying over and over until after a second or so it displays a message: "Run-time error '3420': Object invalid or no longer set." Selecting End or Debug both have the same effect: me.requery is highlighted in yellow and a new "Object invalid or no longer set." message is displayed.
I've tried multiple Ctrl-Breaks, and Escapes, and can't get the console to return any control to me. I can kill the process with the Task Manager, but that of course doesn't let me get into the VBA code to remove my ridiculous me.requery.
Can someone help me out here? Thank you! Dave
After you kill your program from task manager, open your db file(I assume it is .accdb) by pressing down the shift+enter keys.
After you open your file you`ll see your database screen in front of you. Just double click a module to open the VBA editor or simply press ALT+F11. Then, youll be able to find your function.
Related
To preface this, I messed up.
I have a function that runs for each item in the database, to compare against a given value. I added a MsgBox to the code in order to check values for debugging. This function runs when the default form for the project (the one that loads when I launch Access) loads-- on every record in the database. Currently, that's slightly over 13000 items.
Is there any way to suppress the messages, launch the project without loading that form, or edit VBA from the project without launching the project?
EDIT: I've just realized that I can press ESCAPE during a MsgBox display to abort the query. Problem solved.
I have developed a form and I would like to prompt the user to save changes before they navigate away from the modified record.
If the user attempts to navigate away, I want a prompt to appear asking if they wish to save changes, upon which they may select "Yes" or "No".
I have been informed that the Before Update event is the one I need to focus on, but I keep receiving the "the expression before update you entered as the event property setting produced the following error" message.
These are the steps I take before reaching the error:
Change view to Form View
Make a change anywhere in the record via the form
Attempt to navigate away from form via navi-buttons that I put into my form (which work just fine if no changes are made but which fail to do anything if a single change has been made)
Nothing happens, so I revert to Design View, to receive the following error notification
I press OK and then receive this message:
And then I go back to Square One.
Furthermore, any Conditional Formatting has stopped working altogether since this problem has arisen; I do not know for certain if the two are linked, but thought it worth mentioning.
Any ideas how this can be achieved (ideally error-free)? Unfortunately, I cannot post my system up as it deals with highly confidential data.
UPDATE:
I have tried a variety of codes which I have modified, all to no avail. At present, I have removed any such code altogether, but the code I have tried in the past is something to the effect of:
Private Sub Form_BeforeUpdate(Cancel As Integer)
Dim ctl As Control
On Error GoTo Err_BeforeUpdate
If Me.Dirty Then
If MsgBox("Do you want to save?", vbYesNo + vbQuestion, _
"Save Record") = vbNo Then
Me.undo
End If
End If
Exit_BeforeUpdate:
Exit Sub
Err_BeforeUpdate:
MsgBox Err.Number & " " & Err.Description
Resume Exit_BeforeUpdate
End Sub
The default behaviour for a Microsoft Access bound form is to automatically save the record whenever the user does the following:
Moves to another record, Closes The form or explicitly clicks the save button on the ribbon
Therefore I thinks it may be redundant asking the user to confirm if they wish to save.
The forms before update event is generally used for validation so you can check the data that has been entered into the controls and decide in code whether to allow the data to be saved.
To prevent the data from being saved you would change the Cancel variable for example:
Cancel=True
MsgBox "There is a problem with the data entry", vbExclamation, "Please Check Your Data"
The user would then have to press escape or click Undo on the ribbon to escape out of edit mode
Regarding the error you are getting please look into and try the decompile switch documented at the following web page:
Decompile Switch
I occasionally get errors when working with and saving VBA code over and over. Doing the decompile can usually fix this problem. However make sure you do a backup of the database before you start.
Also you could try exporting out your form as a text file and then importing it back in again using the following code which will help if the form has become corrupted:
Application.SaveAsText acForm, stringFormName, stringFolderName & "\" & stringFormName & ".txt"
Application.LoadFromText acForm, stringFormName, stringFileName
Open your form in Design View
Right-click on the form and click on "Properties" from the pop-up menu
Scroll down to the "Before Update" event
All the way on the right you should see a box with an ellipse ("...") in it. Click that box to open the code associated with the Before Update event.
If it opens to a blank sub, you haven't assigned the event properly. Make sure the event is called "BeforeUpdate" (one word) and not "Before Update" (two words).
Your error indicates that this is likely the cause of the issue.
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.
We have an MS Access 2007 database with a simple form displaying table data. We use the Find dialog (click the binoculars on the Home ribbon) to locate records we want. This can cause an error under specific circumstances.
Steps to reproduce the problem:
Open the form.
Open the find dialog.
Edit some field within the record.
The record is now in update mode
(you'll see the pencil in row's
"gutter" area).
Without saving the record, click on
the ALREADY open Find dialog.
Search for a record that can't be
found.
Click on the form again. The record
is still in edit mode (i.e. the
pencil still shows). Attempt a save
or edit some other field.
This message box will display
"Update or CancelUpdate without
AddNew or Edit." You can click OK or
Help buttons.
Clicking the Help button shows:
You tried to call Update or CancelUpdate or attempted to update a Field
in a recordset without first calling AddNew or Edit. (Error 3020)
On a Microsoft Access database engine database, you called the Update or
CancelUpdate method but did not use the AddNew or Edit method before writing
data to a record.
On an ODBCDirect database, this error occurs when you attempt to write data
to a record without first calling AddNew or Edit.
We’ve reproduced this in a new database where there is no VBA code. So the problem is solely within MS Access, and you should be able to reproduce it easily.
If you save the record before doing the find, the problem doesn’t happen. Unfortunately, we have users doing a find while the record is still in edit mode.
We’ve tried setting up form-level, data-field-level, and Access application level events and error handling. Nothing can detect or catch this situation. There is no way within VBA to detect if the Find dialog is active.
Does anyone have any ideas for preventing the error or a way to save the record before the find occurs? Our best thought right now is to create an AutoHotkey or AutoIt script that waits for the Find dialog to have focus. We’ll then send a Ctrl+S to save the current record to force a save.
#CodeSlave's answer suggests a possibility to me:
Instead of simply removing the binoculars from the toolbar/ribbon, instead change what the binoculars do. That is, have it call code that saves the current record if it's dirty and then launches the FIND dialog.
Now, there'd need to be some code to check that a form was open, and that it had a recordsource (testing the .Dirty property errors if there's no recordsource), and that a field has the focus, but all of those things are doable. Likely many of them (except the last) would be taken care of by showing the toolbar/ribbon only when the form is loaded, or by editing the default toolbar/ribbon when the form opens.
But this would be much less crazy than using an out-of-process solution, and your users wouldn't know any difference.
I'd suggest that you've found a bug that was introduced in MS-Access 2007. However, I have not been able to duplicate it on my copy. I presume we're both up to date on our patches, so perhaps there is something more subtle happening.
If you're wanting to force the record to be saved, use one of the the following - not a CTRL-S
if me.dirty then Me.Dirty = false ''(n.b. often the preferred method)
Docmd.RunCommand acCmdSaveRecord
DoCmd.DoMenuItem acFormBar, acRecordsMenu, acSaveRecord, , acMenuVer70 ''(n.b. deprecated)
The problem as I understand it, is that if they edit the form after the "find" is already open and then do the "find" the get the error.
I'd try one of two things:
Find a way to close the built in find form, and do so whenever you make the current record dirty (On Dirty)
Add your own "find" button to the form (not opening the built in find form), and hide the one on the ribbon.
The hack, work-around we came up with was to write an AutoIt script which can watch for when the Find dialog gains focus and save the record if it has changed.
We didn't want to distribute the script separately from the database, so the the script was added to a database table as a Blob. The database's AutoExec macro runs some VBA code that pulls the script out of the Blob table and starts the script.
When the script detects that the Find dialog has focus, the script runs a VBA macro in the database. The macro checks to see if the current record is dirty. If dirty, the macro forces a save. Also, the AutoIt script is stopped when the database is closed.
This is all pretty awkward, but it works.
So, I built a form in Access 2007, and put a subform on it. Then I went to the Property Sheet for one of the controls on the subform and used the builder to point to Code Builder for the OnClick event. This opened the VBA editor & inserted a sub skeleton. I added code here (just a freakin' MsgBox, so far), saved & tried running (opening) the form. It looks good, but clicking the control that has event code yields this, immediately:
The expression On Click you entered as the event property setting produced the following error: A problem occurred while Microsoft Access as communicating with the OLE server of ActiveX Control.
The so-called Help on the error notification is completely useless. It reads:
This error occurs when an event has failed to run because Microsoft Office Access cannot evaluate the location of the logic for the event. For example, if the OnOpen property of a form is set to =[Field], this error occurs because Access expects a macro or event name to run when the event is fired.
Access knew what was going on at design time, since it dropped me into VBA. The Property Sheet entry does read "[Event Procedure]". Is there a secret ninja trick to handling events from a subform, or is it just not possible?
I deleted the problem subform & created a new one. This one seems to work as expected. Go figure....