I wrote a basic report with a selection screen. When I run the transaction I created for it the selection screen displays and is functional. However when I continue past the selection screen the program just silently exits without any warning or error message.
In debugger the program will end silently when it reaches the START-OF-SELECTION program event.
This can happen when you create a transaction for a report with a selection screen but defined it with the incorrect type as a dialog transaction instead of a report transaction.
Recreate the transaction, selecting the second option in the "Start object" block: "Program and selection screen (report transaction)".
Caveat: on some systems a dialog transaction calling a report will still work even though the type is strictly speaking incorrect.
Related
I have a form for viewing data in a table, which can open a pop up form to edit the data.
When data is edited in the pop up form, Access throws a write conflict error upon closing that form and returning to the original.
The strange behavior I'm experiencing is that when I make a change to the popup's class module in VBA, even if I immediately undo the change and save, the error will be resolved exactly once.
To be clear:
I make a change to the popup's class module in VBA (even a change I immediately undo and re-save)
I can open the pop up from my original form, edit records, then close the pop up. No error is thrown on closing the pop up.
I then open the pop up and edit records a second time. Then upon closing the pop up a write conflict error is displayed. This continues each subsequent time.
I now make a change to the popup's class module (again, even a trivial one), the error is resolved for one edit again, and the process repeats.
Does anybody know why this behavior could be occurring? Any help would be much appreciated.
Well the issue centers on if two users, or in this case two bits of code try to edit a record that is already dirty.
If the main form causes the record to become dirty (changed, but not saved), if then you run ANY other code that ALSO changes that data, then you get the conflict.
The simple solution then is to ALWAYS ensure that the the current forms record is safely tucked away and saved before you run + call code that might change that dirty record. And that includes that popup form + class.
So in your code that launches the form/class code? Do this RIGHT BEFORE you launch that 2nd form:
If me.Dirty = True then me.dirty = False
So, the above will safe write out the dirty record, and now you are free to launch/run any other code that might change that record. And because you run the above? Well, the record is not dirty anymore, and thus you should not see nor receive a write conflict error.
So adding a check to save if dirty before you launch/run that additional code/form will resolve this issue. In fact, as a habit, for just about "any" launching of additional UI forms, it a good idea to safe tuck away and save the current forms record when launching additional UI bits and parts.
TL;DR - Subs to do things with data in an access data entry form in other MS applications will sometimes throw a 3021 error for some users but following the exact same steps again doesn't cause an error.
This error is driving me bonkers. I have been searching through questions here and in every other forum I can find and either they don't apply to my situation or they're not giving me enough information to figure out what's going on so I know which step to take next.
I have a split database with BE stored in Sharepoint Lists. FE is just the app on each users local machine. There are quite a few forms and reports and queries, but the general idea is that this is used to log issues between two different departments with a myriad of other information in different formats. There are 3 main forms that are used: the issue entry form, and then 2 forms for each department to update their side's information.
On the main issue entry form there are a few command buttons and the close button is disabled. A couple of these buttons are "Save and new", "Save and Exit", "Delete and Exit". These work as expected and there's no issues there. The other buttons all either open up an Outlook task or open up an Excel file and fill those items with data from the form. All of the subs for the command buttons look similar to the below:
If Me.Dirty Then Me.Dirty = False
Set OApp = CreateObject("Outlook.Application")
Set OTask = "OApp.CreateItem(3)
'Start taking pieces of the form and assigning it to the task
The comment above is where all of these subs misbehave. But the problem and the reason I'm going crazy is because it doesn't happen all the time. Every time this happens (so far about 10 times out of 400 entries) one of my users comes and gets me and I look and the entire form is cleared out like they haven't typed anything so I understand the 3021 error, but the record was saved so it has to at least be reaching the Me.Dirty part of my code. I just don't understand why it's clearing out the form and raising an error when I start trying to do something outside of Access.
With this being intermittent, I don't even know what my next step is to try and find this random bug that chooses to happen or not based on which way the wind is blowing.
Edit 1: So I've dug in and figured out when this is happening and where in the code it's happening. So this only happens the first time the user opens a form for data entry after downloading the latest version. If they close it all down and reopen it, there's no more issues. The reason it seemed so intermittent is because some users would download it Monday. Some would download it Thursday. Some would download it the next week. They just download it the next time they have to use the database. The 3021 "No current record" is actually happening on the Me.Dirty = False line. The If Me.Dirty line is what's actually clearing the form. Since the record was being saved I assumed it was making it past that point, but it's not. The odd thing is that if I use a breakpoint to step through the code I get a 3167 "Record is deleted" error when I get to that line instead of 3021. And the oddest thing about all of this is that it quits happening if the user just closes it all and reopens after a fresh download.
Summary:
If Me.Dirty Then '<--This clears the form
Me.Dirty = False '<--This results in error 3021 because the form is now empty
There are several non-modal forms in ms-access open layered above each other (with a small offset). Every time my VBA program reaches a breakpoint, a stop command or an error the active form is moved to the background (at the end of the Z-order).
I searched the options for a solution for this but did not find anything.
Why is the active form moved to the back and how can I avoid this strange behavior?
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
What are some methods of debugging VBA code?
Specifically:
Stepping through code
Breakpoints and the Stop command
TheDebug command
Locals & watch windows
Call stack
Debugging VBA Code
This page describes methods for debugging your VBA code.
Introduction
Debugging a program is one of the most important steps in software development. Knowledge of VBA's debugging tools can make debugging easier and more productive. This page describes several of VBA's built-in debugging tools you can use when testing and debugging your application.
Stepping Through Code
One of the first methods to debug code is to step through the code one line at a time. To step through code, put the cursor on the first line of code to be analyzed and press F8 or choose Step Into on the Debug menu. The next line of code to be executed will be displayed in yellow background with a black font. Note that the highlighted line of code has not yet been executed -- it is the next line to execute.
If your code calls another procedure, stepping through the code with F8 will cause execution to enter the called procedure in a line-by-line sequence. If you want to execute the called procedure without stepping through it, press Shift+F8. This will execute the called procedure and then pause on the line of code after calling the procedure. If you are already stepping through a procedure, you can press Ctrl+ F8 to resume code execution line-by-line. At any time you are paused either in step-by-step mode or at a breakpoint (see below), you can press F5 or Continue from the Run menu to cause VBA to run to completion or until a pause statement is encountered.
Whenever you are paused in step-by-step mode, you can query or change a variable's value from the Immediate window.
Break Points And The Stop Command
A breakpoint is a marker placed on a line of code that causes execution to pause immediately before executing that line. You can add a breakpoint to a line of code by putting the cursor on the line of code in question and pressing F9, choosing Toggle Breakpoint on the Debug menu, or clicking in the left margin next to the line of code. When a breakpoint is set, the line is displayed in brick-red background with a white font. When you run the code, execution will pause immediately before the line of code with the breakpoint and will display it in yellow background with a black font. Note than the line in yellow has not yet been executed -- it is the next line of code to run.
While the code is paused at the breakpoint, you can issue commands in the Immediate window to change or query a variable's value. To view the content of a variable, enter a ? character followed by the name of the variable and then press Enter. You can change a variable's value by entering VariableName = NewValue in the Immediate window and pressing Enter.
If the Immediate window is not visible (typically at the bottom of the VBA Editor screen), press Ctrl+G or choose Immediate Window from the View menu to make the window visible.
To remove a breakpoint, put the cursor on the line of code and press F9. You can clear all breakpoints by choosing Clear All Breakpoints from the Debug menu or pressing Ctrl+Shift+F9. VBA also provides the Stop command. This simply stops code execution on that line of code and enters break mode.
Once you are finished debugging the code, be sure to go back and clear all breakpoints (choose Clear All Breakpoints from the Debug menu or press Ctrl+Shift+F9) and be sure to remove or comment out all Stop statements.
When you are paused at a breakpoint or in step-by-step mode, you can change the next line to be executed, either before the current line to re-run a section of code, or after the line to skip statements. Right-click the line where you want execution to resume and right-click and choose Set Next Statement or choose Set Next Statement from the Run menu. Execution will resume at the selected line of code.
The Debug Command
VBA provides a Debug object with two properties, Print and Assert that you can use display a variable's value and to control the program flow. Debug.Print will write what follows it to the Immediate window. Code execution is not interrupted. After displaying the text in the Immediate window, code execution continues to run. You can mix literal text with variable names in the Debug.Print statement. For example,
Debug.Print "The value of variable X is: " & X
You can display several variables at once in the Immediate window by separating them with commas. For example,
Debug.Print X, Y, Z
The Debug.Assert command is a conditional breakpoint that will cause execution to pause on the Debug statement if the expression that following the Assert statement is False. For example,
Debug.Assert Var >= 0
This will pause on the Debug.Assert statement if Var >= 0 is False; that is, it will pause if Var is negative. It may seem backwards that execution is paused when the condition is False rather than True, but the Assert method was adopted from the C language, and its usage remained the same as in C.
Be sure to remove or comment out the Debug.Print and Debug.Assert statements when you are finished debugging. You generally don't want these statements to be operative during normal usage of your application.
The Locals Window
The Locals windows allows you to view the value of all the variables in a procedure when you are stepping through the procedure. To display the Locals window, choose Locals Window from the View menu. Using the Locals window is easier to display variable values than examining the value from the Immediate window. For simple variable types (e.g., Long and String variables), the value is displayed on one line. For complex types or objects (e.g., a Range variable), its properties are displayed in a collapsible tree-like structure.
The Watch Window
The Watch window displays all the Watches in effect. You can display the Watch window by choosing Watch Window from the View menu. A Watch is an instruction to VBA to pause code when an expression is True or when the variable being watched changes value. To create a Watch on a variable, open the Watch window and right-click in the Watch window and choose Add Watch... from the popup menu or choose Add Watch... from the Debug windows. In the Add Watch dialog, enter in the Expression text box a variable name whose value you want to watch. Then choose Break When Value Changes. When you run the code, execution will pause at the line after the line that modifies the variable's value. When code pauses, the value of the variable will have already been updated.
To remove a Watch, right-click it in the Watch window and choose Delete Watch from the popup menu. To modify a Watch, right-click it in the Watch window and choose Edit Watch from the popup menu.
The Call Stack
The Call Stack is a data structure maintained by VBA that tracks which procedure called another procedure. For example, if procedure AAA calls BBB which calls CCC, the Call Stack window will display the list of procedures starting with the most recent procedure and below that, the chain of procedures that were executed to get to the current position. You can view the Call Stack by choosing Call Stack from the View menu. This is useful to track the flow of execution that ended up in the current location. Unfortunately, there is no programmatic way to get information from the call stack.
Source: Chip Pearson at Pearson Software Consulting: http://www.cpearson.com/Excel/DebuggingVBA.aspx
I have an Access database where I have code on the On Load event of the main form to set focus to a textbox and load a 'new' record. The code is:
Private Sub Form_Load()
'Makes it so that when frmDiversion_Review loads, it defaults to a new record
DoCmd.GoToRecord , , acNewRec
Me!FromDate.SetFocus
End Sub
FromDate is an unbound date field used in a search/filter section on the header of the form.
I've split the database, and have an .accde file ready to go, but I've noticed that when I close Access when in the .accde file it gives me the following error:
"The expression On Load you entered as the event property setting produced the following error:
****NameOfDatabase**** can't move the focus to the control FromDate."
It does not give an error number.
The code is compiled, and I only get this error using the .accde file. I'm at a loss why the On Load event is even firing when I close Access. Any ideas?
A few weird scenarios may produce this (such as something relating to other forms being closed when you close out...) having references to this form that cause it to open. Hard to say from here.
But there is an easy out... just add this line at the start of the routine
On Error Resume Next
This is safe provided you know there are no real errors in the routine ever, excepting this annoying one that doesn't actually mean anything. If real errors can occur, you will no longer see them if you add this easy-out.
Personally, I'd prefer to find the cause and address it, not least because it seems other forms are trying to open this form while you're busy closing the app, which is an unsettling thought. But... when all else fails, it's a solution.