when you have something like [Forms]![Events]![Event_Type] contained within quotes like you do, it becomes a literal string. In other words, you are not passing the value pertaining to the referenced control, you are passing it's hierarchy (path, beginning with the Forms! collection reference). You have to concatenate, as in
"...Where InStr([Role_Act].[Ev_Type]," & [Forms]![Events]![Event_Type]) & " OR [Role_Act].[Ev_Type] = 'All';"
while being careful to maintain spaces where required, so you don't end up with something like ORmyReferencedControlValueHer
FWIW, I would block capitalize key words like OR, AND, LIKE. It just makes the expression more readable. Just my opinion.
EDIT.
Whoops, I totally missed the fact that this was wrapped in that function even though I copied and pasted it. Focused on this strictly as a sql building statement. I'll leave it in in case it could help in the future. It could prove to be somewhat correct I think, depending on what the function is returning (that value might have to be delimited by ' or #).
EDIT 2. Actually, not seeing what clarification the link provides as they don't cover form control referencing. I think it ought to work as written insofar as returning a value assuming no Nulls, but it won't result in a correctly structured sql statement. If I substitute PARTY for the event type, we ought to get (forgetting about line continuation characters)
"Select [Role_Act].[Role],[Role_act].[Ev_Type] From [Role_Act] Where
InStr([Role_Act].[Ev_Type], PARTY) OR [Role_Act].[Ev_Type] = 'All';"
Not only will there be no string delimiters around PARTY, the result makes no sense as the 1st part isn't being equated to anything, and doesn't have string delimiters either. Not sure of their need - would have to test.
The more we hear silence, the more we begin to think about our value in this universe.
Paraphrase of Professor Brian Cox.