While developing forms in Access VBA I am trying to prevent access from adding a new record and then not giving any warning message. I can stop the record from being inserted but cannot supress the warning message. I have set warnings to false on the after update event (and set warnings to true on the close event ). Can anyone tell me which events I should code for this. The reason for doing this is only while I develop the forms
Are you using a click event for any buttons? If so I would just suppress warnings in there. This setting will remain this way until you close the database and open it again.
DoCmd.SetWarnings (False)
Related
I've been creating an MS Access database with VBA code performing a lot of the necessary actions as the users are not very technically literate. Everything has been working well until today when I noticed a command I was expecting an error from didn't return one.
Code executes until it encounters an error and then just stops with no message. The error details can be access through a messagebox with err.description or similar but no break occurs in the code, just an exit.
I tried creating a button on a new form that divided by 0 to force an error and received no message. I then tried it in a blank database and received the expected error.
So I went back and undid the recent changes I'd made one by one until the error messages returned. Once I set AllowSpecialKeys back to true the error functionality returned. I looked on MSDN and it says the property disables "entering break mode within a Visual Basic module by pressing CTRL+BREAK". It seems that rather than stopping the CTRL+Break combination it just disables VBA's ability to enter break mode.
I have the AllowSpecialKeys set to false to prevent the users from bringing up the Access Object explorer with F11 or the code window with Alt+F11.
So my question is I guess, can I either continue to use AllowSpecialKeys = False and still allow VBA to enter break mode, and if not is there a different way to disable the hotkeys so I can avoid AllowSpecialKeys?
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.
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.
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....