Hello i am using a form in ACCESS to enter new data for a company. First of all the form shows me the current data with a query , and when i want to introduce a new data in the fiels in a line i press Tab many times and when ends it gave me an Error:
the data was added to the database but the data won't be displayed in the form because it
doesn't satisfy
and i close the form and when i open again the form for that company the values that i entered are there...
how can i solve this error , any ideas?
Add some rudimentary error trapping. If your code doesn't already contain it, you really need to read up on it. Any code without some error trapping is just flat out poorly written code.
To start, use a shell like this and modify it appropriately:
Sub|Function SomeName()
On Error GoTo Err_SomeName ' Initialize error handling.
' Code to do something here.
Exit_SomeName: ' Label to resume after error.
Exit Sub|Function ' Exit before error handler.
Err_SomeName: ' Label to jump to on error.
MsgBox Err.Number & Err.Description ' Place error handling here.
Resume Exit_SomeName ' Pick up again and quit.
End Sub|Function
If it hits an error, it will jump to the Err_SomeName: line and then display a messagebox with the error number and description. It will then exit the Sub/Function. What you really want to do is instead of just popping up a messagebox, do something that actually solves the problem. This is what error handling is all about, and it's critical to ensure your program functions exactly the way it's supposed to.
Related
Extremely puzzling:
Upon opening a simple form from another form by vba, the cursor moves to a particular field.
However, when this field is Null there is each second time Error 2110. The syntax to be used changes every time as shown below.
Even more puzzling:
Upon clicking "Debug", the error proves to be imaginary: on the corresponding code line, one can simply continue with F5 or F8 and the procedure ends correctly with the focus where desired.
I found a provisory workaround which does not generate the error message but would like if possible to avoid such limping coding:
'…
Debug.Print Me![MyTextField].Enabled ' always True
Debug.Print Me.Name ' always correct form
Me.Repaint
On Error Resume Next
[MyTextField].SetFocus ' without Me!
Me![MyTextField].SetFocus
' Forms![MyForm]![MytextField] : same result as with Me!]
' one time error with Me! but not without Me!,
' next time vice versa, and so forth…
On Error GoTo 0
'…
When [MyTextField] is not Null, both syntaxes work fine without generating an error.
What is wrong with this .SetFocus command ? "Repairing" the database didn't help.
You can't set focus to the control that has focus. It would give you a very easy way to set up a infinite loop.
You would have to set focus to another control first.
Minty's right. An easy workaround is doing it in an if statement or create a bool to see if IsNull(fieldhere) = true then exit sub or your action here. Or more simply maybe try:
if MyTextField.gotfocus = true then
do something
else
MyTextField.setfocus
I recently ran into this issue in something similar and had to create a public bool function and test it on load events. Please note that I'm a beginner in access so there's probably many better ways to complete this :)
I've got a set of fairly complicated table validation rules that I'm using to keep my data clean in one of my MS Access tables. The rules appear to be working well, but when a rule is violated it generates a nasty-looking error message. The whole string of rules comes up in the message - not exactly user-friendly.
I've tried to replace the message using code similar to this in the form's OnError event:
Private Sub Form_Error(DataErr As Integer, Response As Integer)
If DataErr = 2601 Then
MsgBox ("Case Number already entered")
Response = 0
End If
End Sub
However, apparently I haven't managed to find the correct error number because the If statement never fires. I checked here, but apparently it's not 3317 or 4001.
Also, when I removed the If statement and just had the MsgBox fire on any error, the standard error came up along with the message box - it's not being replaced.
Any idea how to address these issues?
If I don't fill out all the required fields in my form, I get an ugly error when I click the "x" in the upper right corner.
I would like to override the default error with a custom error message, but I can't figure out which VBA event to associate this code with. the Form_Close event doesn't seem to work when I put an error handler in there.
Access 2010
Private Sub Form_Unload(Cancel As Integer)
On Error GoTo Err_Unload ' Initialize error handling.
'insert routine
Exit_Unload: ' Label to resume after error.
Exit Sub ' Exit before error handler.
Err_Unload: ' Label to jump to on error.
'MsgBox Err & " " & Error$ ' Place error handling here.
Resume Exit_Unload
End Subenter code here
Still receiving errors even while using this code.
Private Sub Form_Unload(Cancel As Integer)
On Error GoTo Err_Unload ' Initialize error handling.
' Code to do something here.
Exit_Unload: ' Label to resume after error.
Exit Sub ' Exit before error handler.
Err_Unload: ' Label to jump to on error.
'MsgBox Err & " " & Error$ ' Place error handling here.
Resume Exit_Unload
End Sub
When you attempt to close a form which has unsaved changes to the form's current record, Access will first attempt to commit those changes. You can't intercept that action from Form_Unload or Form_Close.
BTW, although you didn't mention it, I would expect you to see the same thing when navigating to a different record if the record you're navigating away from includes unsaved changes with missing values for required fields.
In the case where your form's record source includes a table with an autonumber field, use the form's before update event to check whether required values are present. If there is no autonumber field involved, consider doing the checking from both the form's before insert and before update events.
However if the whole point of this is to get a friendlier message for a missing value in a required field, see whether changing the table's properties is satisfactory. For example, you could set Required to No, then use Is Not Null for the field's Validation Rule which would allow you to assign your friendly text message as the field's Validation Text property.
From http://office.microsoft.com/en-us/access-help/order-of-events-for-database-objects-HP005186761.aspx,
Similarly, when you close a form, the following sequence of events
occurs:
Exit (control) → LostFocus (control) → Unload (form) → Deactivate
(form) → Close (form)
If you've changed data in a control, the BeforeUpdate and AfterUpdate
events for both the control and the form occur before the Exit event
for the control.
What's likely causing your error is the BeforeUpdate event when the form tries to save your changes, but fails because you haven't filled in required fields. You can create some validation code and run it in the BeforeUpdate event for the form to make sure everything is OK and send the appropriate message to the user.
You might like to use:
Private Sub Form_Unload(Cancel As Integer)
End Sub
There is actually a form event called On Error, which has two arguments: what the error is and what response Access should perform.
I am writing a VBA function to import data from one table to another in Access. The table I'm importing into has more strict data constraints (i.e. types, size etc.), so I'm expecting a lot of errors.
Rather than sift through every VBA error that comes up, I want my recordset loop to skip the entire current record and make a note of it in a separate table whenever it runs into an error. So every other line I've inserted On Error GoTo RecordError. But for some reason it's not handling every error. My code just breaks and tells me what the error is. I have the "Break on Unhandled Exceptions" option checked already.
Here's a screenshot that should explain it.
Why would it be breaking on the line immediately following an Error handler?
I think you're not understanding how VB(A) error handling works. Follow these principles:
An On Error... statement only applies to the routine (Sub or Function) in which it appears (though it will also catch errors that "bubble up" from routines that are called from within the routine in which you use it).
On Error sets a state. That is, Once you issue an On Error... it remains in force for the rest of the routine, unless superceded by a new On Error....
There are four forms of On Error...:
On Error GoTo <label>: <label> must be defined in the same routine, by writing the label name immediately followed by a colon (:) on a line by itself.
On Error Resume: immediately retries the error-throwing statement. Hardly ever used, since it's potentially infinite.
On Error Resume Next: ignores the error & continues. Sometimes useful at the end of routines for cleanup (for instance, if you want to Close a Recordset that may or may not be open). Alternatively, this form can also be used if you check the Err object immediately after any potentially error-throwing line (if Err.Number is zero (0), the statement succeeded without throwing an error). This is way too much work for most situations.
On Error GoTo 0: turns off error handling.
Given this, it's usual to place the On Error... statement immediately followng the routine's declaration (the Sub or Function statement), though some people put their Dim statements in between. If you want to temporarily change the manner of error handling within a routine, put the "new" one right before the code to which it is to apply, and (if used), the "revert" (reissuing the original), right after.
Even given all that, I have no idea why it would break on the error-throwing line when "Break on Unhandled Errors" is selected, unless you've managed to confuse it so much that it thinks there's no active error handling (and I'd be surprised if it compiled if that were the case).
Note that David Heffernan gave you the essential part of this in his answer, and it was here before mine....
The reason it is not working is because you cannot use On Error Goto ... within an error handler.
see http://www.cpearson.com/excel/errorhandling.htm
you cannot use On Error to skip a few lines, instead on error should go to a error handler which then resume's to the desired next line (in your example you could probably get away with one error handler which contains a resume next which will take you back to the next field).
thanks to Tim Williams on this question: The second of 2 'On Error goto ' statements gets ignored
and BTW ParseInt on a ZIP will destroy zip codes that begin with a 0, zipcodes should probably be treated as text.
You need to place the On Error line before the code whose errors you wish to handle.
What's more you only need to have one On Error line. The error handler then stays active until the subroutine exits or you execute another On Error statement.
Error handling with VBA is a real PITA. I'd propose you to have a look at this answer to the 'MS-Access, VBA and error handling' question, and have it adapted to your own situation. You can easily write down some code that will store all your error messages in a table, building a de facto error reporting system.
Setting the debug mode to 'break on all errors' will make the program execution stop at the line that causes an error even when the error handler has been correctly written. This can be confusing as it appears that error handling is not working.
Nobody has really answered your question.
Say your code is something like this (a skeletal framework):
Public Sub MySub()
On Error GoTo errHandler
Dim rs As DAO.Recordset
Set rs = CurrentDB.OpenRecords([SQL SELECT])
If rs.RecordCount >0 Then
rs.MoveFirst
Do Until rs.EOF
[do whatever that produces the error]
errSkipToNext:
rs.MoveNext
Loop
End If
exitRoutine:
If Not (rs Is Nothing) Then
rs.Close
Set rs = Nothing
Exit Sub
errHandler:
Select Case Err.Number
Case X, Y, Z ' where these are error numbers you want to ignore
Err.Clear
' do whatever it is you need to do in order to record the offending row
Call RecordError(rs!PK, Err.Number) ' PK is a field that identifies the bad record
GoTo errSkipToNext
Case Else
MsgBox Err.Number & ": " & Err.Description, vbExclamation, _
"Error!"
Resume exitRoutine
End Select
End Sub
In this code, you use a SELECT CASE in your error handler to decide which errors you want to ignore. In my code framework above, I listed the error numbers as X, Y, Z, but you'd replace that with the real error numbers you want to ignore, instead.
You don't want to ignore every single error because you might end up ignoring important errors elsewhere in your subroutine. If you don't want to figure out what the limited number of errors you want to ignore happen to be, I would suggest that you set a flag at the beginning of the code block that produces the errors you want to ignore, then use an `If bolErrorInCodeBlockToIgnore Then to decide if you're ignoring all errors or not. Something like this:
Public Sub MySub()
On Error GoTo errHandler
Dim rs As DAO.Recordset
Dim bolErrorInCodeBlockToIgnore As Boolean
Set rs = CurrentDB.OpenRecords([SQL SELECT])
If rs.RecordCount >0 Then
rs.MoveFirst
Do Until rs.EOF
bolErrorInCodeBlockToIgnore = True
[do whatever that produces the error]
errSkipToNext:
rs.MoveNext
Loop
End If
exitRoutine:
If Not (rs Is Nothing) Then
rs.Close
Set rs = Nothing
Exit Sub
errHandler:
If bolErrorInCodeBlockToIgnore Then
Err.Clear
' do whatever it is you need to do in order to record the offending row
Call RecordError(rs!PK, Err.Number) ' PK is a field that identifies the bad record
bolErrorInCodeBlockToIgnore = False
GoTo errSkipToNext
Else
MsgBox Err.Number & ": " & Err.Description, vbExclamation, _
"Error!"
Resume exitRoutine
End If
End Sub
I would much prefer the first, as I'm a firm believer in only ignoring known errors, not any old error that happens. But it might be quite difficult to come up with tests that will produce all the possible errors you want to ignore.
I have seen error handling fail too. Here is one example.
Public Function Have(ByVal item As Variant) As Boolean
'Have = Have data. Simplifies handling nulls and empty strings in validation code
On Error GoTo Procerr
If IsNull(item) Then
Have = False
**ElseIf Len(Trim(item)) = 0 Then 'Faster than Item <> ""**
Have = False
ElseIf item = 0 Then
Have = False
Else
Have = True
End If
exitproc:
Exit Function
Procerr:
'Errors sometimes occur if an unbound control is referenced
Have = False
End Function
The code sometimes fails on the line flagged with **. Here is the error message.
Note that the error handler has failed. In this case, the form that called the code returned had its recordsource set on the fly to an empty recordset, hence the fields on the screen are not visible. The form is a continuous form, so records and fields are not visible when the form is loaded with an empty recordset. The have() function is not directly called by my code, but somehow seems to be triggered by the me.requery method. The have() has been called hundreds of millions of times in my code but this is the only instance that causes it to fail and the error handler is not involked.
To Lance Roberts re original question. utf-8 unicode can sometimes play havoc with ms-access as it seems to be allow data to be confused for instruction codes (my guess). utf-8 can get into your data if data was originally loaded from a text file. utf-8 with a byte order mark (BoM) is particularly nasty. When you run some procedure that works with the data, strange errors can occur and it may look like your file has become corrupt. In other cases, text handling functions give wrong answers, e.g. Mid() will see the BOM and if you specify a starting point will start at the BOM, but Len() ignores the BOM. I am speculating that if you have this issue, then ms-access may not handle errors correctly. I have had similar issues importing data and importing utf-8 as ANSI was the cause. Note that utf-8 and ANSI are identical most of the time for plain English data so your errors may not be on every line. My errors were mostly with time-date fields. Try exporting the data first and then forcing it to be ANSI and remove any BoM and and reimporting it.
can't believe I am losing so much time on this one.
I have an order form, and when I click on a button "reports", a dialog
pop ups with a list of different reports to chose from. Double-clicking selects
and starts the correspondent report.
On one of these reports, there is an unbound text box I need the user to enter data with.
The ControlSource of this field is set to its Name property.
When the report is started, an input box appears with an OK and a Cancel button. Whenever I enter some data, all is fine.
But when I click on Cancel, the app crashes and I get an errormessage:
"Runtime Error 2501: The Action OpenReport has been canceled" (translated from German).
The Report is called through this code:
DoCmd.OpenReport vBerichtName, nAnsicht
End If
On Error Resume Next
DoCmd.Close acForm, "F_BerichtDrucken"
On Error GoTo 0
1) Why does the error handling not kick in?
2) I googled and found lots of weird solutions for this, like the official Microsoft one saying you need to install/update a printer driver (come on...). None helped.
I am doing this for a friend and I normally work on linux/php,java, etc. I apologize if the solution is somewhat obvious or something like that.
Ditto to Phillipe's answer. you didn't give us the whole procedures but you need to do something like this...
Sub MyButton_Click
On Error Goto myError
DoCmd.OpenReport vBerichtName, nAnsicht
MyExit:
Exit Sub
MyError:
If Err.number = 2501 then goto myExit
msgbox err.description
goto myExit
End Sub
This is a common error but you can catch it like any other error and ignore it if is 2501.
Seth
The error probably comes from the DoCmd.OpenReport line. This is why the error handler does not work.
I guess the value you requested is somehow mandatory in the report. Did you try to put your error management line before the docmd.openReport?
Check your default printer. I was getting the same error & all my code was working properly. Someone using the computer set the default printer to a label printer. Somehow Access was checking the printer & knew it didn't have the correct size settings to print so it stopped the displaying of the report.
I changed the default printer to another full size sheet printer and it worked fine.
I hope this helps someone because I was at a loss when it first occurred.
OK, it works now.
After your suggestions, I put the code like this:
On Error GoTo CancelError
If Not IsNull(vFilter) Then
DoCmd.OpenReport vBerichtName, nAnsicht, , vFilter
Else
DoCmd.OpenReport vBerichtName, nAnsicht
End If
CancelError:
DoCmd.Close acReport, vBerichtName
DoCmd.Close acForm, "F_BerichtDrucken"
Echo True ' this did the trick
Exit Function
As soon as I put Echo True into the error handling, it works
now smoothly, going back to the previous form and allowing
to continue to work - looks like "Echo" is kind of a refresher for the screen...?