[AccessD] Determining the records about to be deleted by the DBEngine

Bill Benson bensonforums at gmail.com
Tue Sep 19 12:30:55 CDT 2017


And - now I have a new problem. If the user is sitting in a record and
presses Ctrl A which selects all the records, this does not fire the
mousemove event at all. And therefore when they press the Delete key I have
nothing to loop through. It seems I am forced to find some way to determine
what records are about to be deleted, in the BeforeDelConfirm event,
without use of MouseMove, otherwise I cannot perform my additional tests
and prompts to the user.


On Tue, Sep 19, 2017 at 1:05 PM, Bill Benson <bensonforums at gmail.com> wrote:

> I am a little surprised no one responded ... but I will report that the
> "issue" I thought I had turned out to be an artifact of Access firing the
> MouseMove event one additional time as it settled on the record below the
> one(s) selected - whether that be an existing record or a new record - but
> this turned out to be after the BeforeDelConfirm event had fired. Thus, the
> records I was testing in BeforeDelConfirm were only the ones selected at
> the time the user pressed delete. So all is well.
>
> On Mon, Sep 18, 2017 at 6:16 PM, Bill Benson <bensonforums at gmail.com>
> wrote:
>
>> How, in the BeforeDelConfirm event, can I determine what records are
>> about to be deleted so that I can give the user more info than Access's
>> "how many records will be deleted" message? For example, related records in
>> other tables that I have to maintain the cascading deletions for (the data
>> integrity is not set, so I have to take care of the cleanup in code)?
>>
>> When I put code to test recordsetclone, form.Selheight, Form.Seltop kind
>> of stuff in MouseMove of the datasheet form - I get a different set of
>> records by the time Access condenses the data set (I think it ut retriggers
>> MouseMove on its own, when pushing the user onto the next available record
>> that would exist post-delete, while showing the transactional view. If the
>> user cancels, this problem goes away but if the user does not cancel, I do
>> not want Access reporting on the record below where the user is deleting
>> from, the way it seems to now.
>>
>> I would be surprised there is nothing I can use like Access natively uses
>> to identify which records are about to be deleted?
>>
>>
>> Form Class Module
>> Dim arSelectedItems() as long
>> Dim StrID as String
>>
>> Private Sub Form_BeforeDelConfirm(Cancel As Integer, Response As Integer)
>> Dim i As Long
>> For i = 1 To UBound(arSelectedItems)
>>     strID = strID & "," & arSelectedItems(i)
>>
>> Next
>>
>>     Debug.Print Debug.Print Mid(strID, 2)
>>
>> End Sub
>>
>>
>> Private Sub Form_MouseMove(Button As Integer, Shift As Integer, X As
>> Single, Y As Single)
>> Dim rst As Recordset
>> Dim F As Form
>> Dim strID As String
>> Set F = Me
>> Dim i As Long
>> ReDim arSelectedItems(0 To F.SelHeight)
>> If Me.SelHeight = 0 Then
>>     Exit Sub
>> End If
>> Set rst = Me.RecordsetClone
>> rst.MoveFirst
>> For i = 1 To F.SelTop - 1
>>     rst.MoveNext
>> Next
>> For i = 1 To F.SelHeight
>>     arSelectedItems(i) = rst!ID
>>     strID = strID & "," & arSelectedItems(i)
>>     rst.MoveNext
>> Next
>> Debug.Print Mid(strID, 2)
>> End Sub
>>
>
>


More information about the AccessD mailing list