VBA ACCESS FORM EDITING ISSUE AFTER Do.CMD.FindRecord - vba

strSQL = " select top 1 id from employees "
Set rs = CurrentDb.OpenRecordset(strSQL)
If Not rs.EOF Then
DoCmd.FindRecord rs(0), , True, , True
rs.Close
End If
the Error is a Write Conflict with the Save Record grayed out.
The DoCMD line is whats causing the error.
I am trying to automate when someone enters an ID and its already there to go to that record.
I have this working but when I try to edit the form I get an error stating that someone else
is trying to use the same form. I have isolated the code that is causing it but can't figure
out how to fix it.

Rebooted that didn't help so I moved the table from sql to Access and that sovled it.

Related

Programmatically find and navigate to record on subreport in MS Access using VBA?

In Access, I can navigate to a record in a subform by using code similar to:
Dim rs As Recordset
Set rs = Me.Form.RecordsetClone
rs.FindFirst "CodeID = " & MyID
Me.Form.Bookmark = rs.Bookmark
Is there any way to do something similar with subreports, or any other way to navigate to a record within a subreport without using filters to only show one record? I'm looking to still be able to see the other records in the report, having the focus jump to the relevant record.
I figured out a way to do it. Assuming the report is embedded as a subreport:
Me.rptTest.SetFocus
DoCmd.SearchForRecord , "", acFirst, "[IDField] = " & RelevantID

MS Access VBA Update Query to Clear All Check Boxes On a Form Not Working

I have a button on my MS Access form that uses VBA to update the modified date/time stamp on all records on a datasheet style form that have a checkbox checked in a field called "Confirm Existing Update". After it makes these updates, it is supposed to clear all of the check boxes. This is currently accomplished via a simple SQL update query that executes via VBA once the date/timestamps have been updated:
"Update [CMO Deviations Tracker] SET [CMO Deviations Tracker].[Confirm Existing Update] = FALSE WHERE [CMO Deviations Tracker].[Confirm Existing Update] = TRUE"
The problem is that the query doesn't seem to want to clear the last checkbox checked (in the last row that was interacted with). I've tested the query by copy/pasting it into a blank query design window and it works perfectly there (clears all check boxes, including the final one clicked). So far, I've attempted to add the following to my form button's VBA code:
Shifting the record to the next line before running the Update query via "Me.Recordset.MoveNext"
Saving the last record interacted with via "If Me.Dirty Then Me.Dirty = False"
I added "Forms![CMO Deviations Tracker].Requery" to the end of the code to ensure that I was seeing the latest info
None of these seem to result in the clearing of the last checkbox checked. What could be causing this?
EDIT: I just tried running my separate Update query while the form was open immediately after trying and failing with the button. It failed to remove the last checkbox due to a "lock violation". Interesting...
EDIT2: So the only thing that I've found to work (as a manual workaround) is to check the boxes for all of the rows that I want to update the timestamp for, and then check and uncheck the box for one additional row before clicking the button. Access will then clear all of the desired check boxes like it's supposed to.
EDIT3: Just a point of clarity. The updating of the timestamp on the last record checked appears to work perfectly. It seems like, for whatever reason, it's only the "Confirm Existing Update" checkbox field that is getting locked. Thinking that it could be the method being used, I attempted to clear these checkboxes by editing the Recordset and using a loop to make the "Confirm Existing Update" field for each of the rows in the Recordset equal to "False". It still seems to clear all check boxes except the last one, only this time, the vba code will error out on the final line by saying "Could not update | currently locked". Same error, completely different implementation.
EDIT4: Updating the "Record Locking" property of the form to either "Edited Record" or "No Locks" seems to fix the issue, but only if done as part of the button click code. If I put VBA to update this property in the "On Open" event trigger of the form, or simply update the property in the GUI, it doesn't seem to fix the issue - even with "No Locks" set as the default property. What the heck?
EDIT5: Per request, the following is the VBA from my button. Please note that I've updated the methodology to update the check boxes using a DAO.Recordset, rather than the original SQL Update query.
Private Sub Command187_Click()
Dim Temp_ID As String
Dim DBS_Temp1 As DAO.Database
Dim DevTracker As DAO.Recordset
Dim DevUpdates As DAO.Recordset
If MsgBox("This will confirm that the latest update provided is still current for all items with the 'Confirm Existing Update' box checked above. Are you sure that you want to do this?", vbYesNo) = vbYes Then
Set DBS_Temp1 = CurrentDb
Set DevTracker = DBS_Temp1.OpenRecordset("CMO Deviations Tracker")
Set DevUpdates = DBS_Temp1.OpenRecordset("Deviation Updates")
DevTracker.MoveFirst
DevUpdates.MoveFirst
Do Until DevTracker.EOF = True
If DevTracker![Confirm Existing Update] = True Then
DevUpdates.MoveFirst
Temp_ID = "[Deviation ID] = '" & DevTracker![Deviation ID] & "'"
DevUpdates.FindLast (Temp_ID)
DevUpdates.Edit
DevUpdates![Status Update] = DevUpdates![Status Update] & " "
DevUpdates![Status Update] = Left(DevUpdates![Status Update], Len(DevUpdates![Status Update]) - 1)
DevUpdates.Update
DevTracker.Edit
DevTracker![Confirm Existing Update] = False
DevTracker.Update
End If
DevTracker.MoveNext
Loop
DevUpdates.Close
DevTracker.Close
Set DevUpdates = Nothing
Set DevTracker = Nothing
Set DBS_Temp1 = Nothing
MsgBox "Existing updates for the selected deviations have been confirmed."
Else
DevTracker.MoveFirst
Do Until DevTracker.EOF = True
DevTracker.Edit
DevTracker![Confirm Existing Update] = False
DevTracker.Update
DevTracker.MoveNext
Loop
MsgBox "Update Confirmation Cancelled."
Forms![CMO Deviations Tracker].Requery
Exit Sub
End If
Forms![CMO Deviations Tracker].Requery
End Sub

VBA ADO: Could Not Use <Filename>; file already in use

It's been a long time since I've had to do any development in Access, so hoping I can get some help. I have a split Front End/Back End solution that I've built. The Back End resides on a server, the front end gets copied down to user's desktops (and they use runtime Access 2013). I'm using Access with VBA and ADO connections/recordsets in order to do all record actions (Select, inserts, updates mostly).
Two intermittent issues have cropped up and I'm at a loss - this is one of them. From time to time, some users will get the error "Could not use "(back end Filename)"; file already in use." (where (back end filename) is my back end db name & location". When users get this message, they close out, re-open and try the same data entry and it works without a hitch. Here's the code:
Private Sub SetProblemCode()
On Error GoTo ErrorHandler
strSQL = "SELECT Problem_Code_ID, Problem_Code, Problem_Description FROM Problem_Code ORDER BY Problem_Description"
con.Open strConString
rstProblemCode.CursorLocation = adUseClient
rstProblemCode.Open strSQL, con, adOpenForwardOnly, adLockReadOnly
cboProblemCode.RowSourceType = "Table/Query"
Set cboProblemCode.Recordset = rstProblemCode
rstProblemCode.Close
con.Close
Exit Sub
ErrorHandler:
CriticalError Err.Description, Err.Number, Me.Name, "SetProblemCode"
End Sub
The rst and con objects are defined at the global level, a practice I've used in other solutions before but I'm questioning if that's some of the problem. I'm also questioning the cursor location, type and lock type I'm using, although it seems correct - I'm not altering data, just copying a recordset to the Access combo box.
I'm hesitant to make sweeping changes when it seems like the user closes out and tries again and it works just fine. Any thoughts?

Access Update Query Crashes Program

I've recently moved a db built in Access 2010 to Access 2013. It was working fine for a while then it suddenly started crashing (i.e. not responding) whenever a certain table is updated using VBA. I can run the query on its own without any problem but can't call it in VBA. Below is an example of the code that would cause a crash. Any attempt to update this table causes it to crash:
Sub ShipOrder(OrderID As Long)
Dim strSQL As String
On Error GoTo ErrorHandler
strSQL = "UPDATE Orders SET StatusID = 20 WHERE ID = " & OrderID
CurrentDb.Execute strSQL, dbFailOnError
Exit Sub
ErrorHandler:
MsgBox Err.Description
End Sub
I've already moved all tables, forms, etc. to a new database just in case the old one was corrupted but the problem persisted.
Any suggestions on what is causing this error are greatly welcome!
Thanks.
Sound like your linked DB is the problem..
Did you try-
docmd.RunSQL ""
may be CurrentDb on CurrentDb.Execute is the problem...
good luck..

Run query from VB in MS Access

I'm trying to set the sql code for a query and then run the query from VB. The problem is that when I change the sql dynamically, the VB opens the query but does not refresh it. It still shows results from old sql. If I check the sql, it has changed, and if I then run the query (! button), it runs with the new sql.
I'm doing:
Set qdf = CurrentDb.QueryDefs("temp_query")
qdf.SQL = SQL_query_string
MsgBox (qdf.SQL)
DoCmd.OpenQuery ("temp_query")
With SQL_query_string containing the new, dynamically generated sql. The message box shows me that I indeed have the new string. And, as I said, I can check it in the query itself, and it has changed, but DoCmd.OpenQuery("temp_query") seems to just give the query the focus, not actually running it. What command runs it with the fresh sql?
If the query is already open, you need to close it and then reopen, interestingly enough, you probably do not even need to check if it is open, you can just close and then run the code.
DoCmd.Close acQuery, "temp_query"
Set qdf = CurrentDb.QueryDefs("temp_query")
qdf.SQL = SQL_query_string
'MsgBox (qdf.SQL)
DoCmd.OpenQuery "temp_query"
Make sure you have not used Set Warnings or On Error resume next, because they will mask errors.