It's an adaptation of this technique:http://allenbrowne.com/ser-18.html designed to open a form to the same record it was on when the previous session was closed. (The OnLoad event reads the information stored here.) I used it while developing the subform as an independent form, and it worked fine. The codeblock from which I extracted the above line is (without the DIM statement):
Code:
If Not IsNull(Me!sbfShotList!Form.ShotNumber) Then
Set rs = CurrentDb().OpenRecordset("tblInterSessionPlacemark", dbOpenDynaset)
With rs
.FindFirst "[fldVariable] = 'ShotIDLast'"
If .NoMatch Then
.AddNew 'Create the entry if not found.
![fldVariable] = "ShotIDLast"
![fldvalue] = Me!sbfShotList.Form.ShotNumber & Me!sbfShotList.Form.ShotNumSuffix
![fldDescription] = "Last Shotnumber for form " & Me!sbfShotList.Form.Name
Else
.Edit 'Save the current record's primary key.
![fldvalue] = Me!sbfShotList.Form.ShotNumber & Me!sbfShotList.Form.ShotNumSuffix
.Update
End If
End With
rs.Close
End If
Set rs = Nothing
This is an adaptation of what I had in the subform originally, with object references changed to refer to the form now as a subform. The reason this has to now be in the main form is the main form closes before the subform. (I learned the hard way that this is not the symmetrical reverse of when they open, whence the subform opens first )
As mentioned, the above code works when run. It only draws the error when moving from form view to design view. I've now found various references over the years where people report issues with this error. Their situations seem similar to mine - many happening where subform controls are referenced from a main form event - though no evident cause or solution. One person suggested it has something to do with the timing of the closings, that maybe the subform objects are destroyed earlier than when the main form unload fires, and that one should simply trap the error and move on. I was hoping someone here may have a more concrete explanation/solution.
Thanks for any help, Ron