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.
Related
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.
I already turned off auto-syntax check but this problem still persists. Whenever I try to modify a time, let's say from 08:30:00 AM to 08:30:05 AM, Access sometimes fills in a zero after I backspace to clear the 0. It forces me to have to quickly change the value otherwise it gives me an annoying pop up message saying syntax error....but the editor caused the error, not me!
How do I fix this? Please help me fix this.
This happens when code is running, which forces Access to constantly compile the VBA source code.
Typical example: a form is open that uses the OnTimer Event (has TimerInterval > 0).
To prevent this: Close all forms while editing code (Design view is ok).
If it's not forms, press the "Stop" button in the VBA toolbar (the blue square) to stop all running code.
I'm having this InvalidOperationException
An error occurred creating the form. See Exception.InnerException for
details. The error is: Object reference not set to an instance of an
object.
pointing at this line of code:
Private Sub BeginningBalancesToolStripMenuItem_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles BeginningBalancesToolStripMenuItem.Click
inventory.MdiParent = Me <--error here
inventory.Show()
End Sub
EDIT:
Im only using drag and drop for creating controls from the toolbox. The thing here is, everything works fine until I relocated AND decided to return panel_001 to its previous location by pressing ctrl-z in the inventory.vb during design time to revert the change I made. The program runs fine without error prior to that specific panel relocation. I never edited any codes in the designer.vb and in the inventory class. I strongly believe that a piece of code wasn't properly restored at the ctrl-z action in the inventory.Designer.vb. Is this a visual studio bug?
EDIT: I tried creating a new winform and attempted to start fresh by foolishly copying & pasting all the controls and the forms' class and was no good. I assume the problem does not lie under the striked-out line above.
The Winforms designer has a knack for tripping really mystifying design-time exceptions. A side-effect from its strong WYSIWYG design, it will run some event handlers at design-time. Like Paint, making a control look the way it does at runtime. Nice, but that does come with a price. This can easily cause an exception if such an event handler was not written to operate correctly at design time. You are supposed to use the DesignMode property to keep the code safe.
Coming up with a way a Click event handler could run at design-time however requires massive amounts of imagination. That is an event that will not run at design time, the designer uses a layered window that intercepts any mouse clicks, using them for design use instead. Like selecting a control or displaying the design-time context menu.
I have actually seen the Click event of a ToolStripMenuItem run. The designer is not 100% watertight but it happened just once and I was hacking the code pretty hard. Coming up with a way that it could possibly run by using Undo is going to be difficult. Maybe you give it the Ctrl+Z shortcut, don't assume that guess is credible.
The way to deal with incomprehensible black magic like this is to just dismiss it and move on with your life. You just don't stand much of a chance to diagnose it and if you do then there's nothing you can do about it anyway because this isn't your code. Well, other than the need to use DesignMode, that may well be necessary. Not in this case. The only thing you have to watch out for is that such an exception did not destroy the InitializeComponent() method. That can happen too, you notice by controls being missing when you re-open the designer. Very unpleasant, you do need a good backup copy in source control to recover from that lossage.
OK! after giving it a few more tries, I found the answer. After the exception shows, copy exception details to clipboard and then I pasted it on Notepad. It had a lot of texts but the bottom part was the important one:
--insert wall of texts here-- in C:\Users\Ellen\Documents\Visual Studio
2008\Projects\SampleApplication\SampleApplication\Forms\inventory.Designer.vb:line
760 at CabuyaoWaterDist.inventory..ctor() InnerException:
It pointed me out to the specific line in the designer where the ctrl-z did not properly revert one of the label's caption
I am programming the On_Click method for the button labeled "View" in the first printscreen below. The method will load a form with data corresponding with the specific address id in the row containing the "View" button. This code worked perfectly when pointing to a target form called "Addresses". However, when I decided to rename the form "Address", I started receiving the following error message when clicking on the view button:
I did some research on the web about this error message, which lead me to try to delete any outdated references in the VBA editor. But when I clicked on Tools-->References in the VBA editor, I got the following error message:
It seems that MS Access' entries in the system registry might have been corrupted. But I am not certain of this because the documentation of this on the web is sparse and inconsistent.
Here is a link to the database on a file sharing site: http://jmp.sh/b/9Uyx6J2YzWbs8zPq2h6g
If the problem is in the database, you can recreate the problem by opening the form "Main" and clicking on the button "View" for the record shown in the printscreen above, or for other records.
Can anyone show me how to get past this error message?
my advices?
You could rename your Forms!....SourceObject to "Address" instead of "Addresses"
You could copy/paste the form, delete the original, and retry
You could install a decent debugging tool like MZ-Tools for VBA, that will help you manage your errors. Check the details here
EDIT: I used to get similar bugs years ago, when I was writing specific form event procedures. As we decided to switch to a model where forms did not need to be debbuged anymore (check this here), we stopped getting this kind of message. And I think I forgot the trick we used to solve this kind of error. If I were you:
I'd try to open another access database and import all objects ...
I'd put aside/cancel the faulty onClick procedure
And I'd install MZ Tools because otherwise VBA debugging is a nightmare ...
Since access was not liking the command button in each record of the continuous form, I choose to put the view button's logic in the on click event of a text box in each row, which I configured as enabled but locked. This produces a separate link from each record of the continuous form to a unique detail page with more of the chosen record's data.
This solution works perfectly, and is enabling me to move on with my other coding.
However, it would be nice if someone else were able to show how to get the command button solution to work.
I found that for a couple of hours this code worked:
If KeyCode = 37 Then
Me.Text12.SetFocus
End If
Then it mysteriously stopped working. I thought it might have had something to do with processing the OnEnter subroutine (I move the cursor to the end of the text field).
However editing out the OnEnter subroutine didn't help.
The only other thing I'd done was change my input/keyboard language (to be able to type quote marks and have them appear immediately, huzzah!)
I now have this code:
On Error Resume Next
If KeyCode = 37 Then
Me.Text12.SetFocus
Me.Text12.SetFocus
End If
Which works. So I know the 50+ pages of search results for SetFocus not working which relate to it being hidden, disabled, not visible, out for tea with the vicar etc do not apply here.
I've also tried setting the focus to another control first, and liberally applied DoEvents as well, neither of which helped.
Has anyone run into anything similar or is this just a really weird Heisenbug?
You must have something else going on. Set a breakpoint on the first Me.Text12.SetFocus and watch what happens when you step through the code (F8).
I suspect that you have another process being triggered that's cancelling the first Me.Text12.SetFocus.
Another possibility is your DB as corrupted. This is something Access is prone to do, especially with lots of edits to the forms and/or reports. Go to File - Info, then click on Compact & Repair Database.
It's not a bad idea to have Access do this automatically whenever you close it. Go to File - Options - Current Database (tab), then check Compact on Close.