IMHO, to do exactly as you say in one form loaded with one recordset may not be possible. Consider the following:
1 - as long as the data source isn't a table, you should be able to base the form on a query. However, #3 requires that you load all records, but apply a filter where the Status is Null. Whatever sort order you apply in the query would dictate what comes "first" as long as it works satisfactorily.
2 - since the filter shows only where Status is not C (it is Null) you will get no C status records anyway.
3 - this is where the problem comes in. If you base the apply/remove filter decision based on a form textbox containing the ticket number and that textbox is bound, then the problem becomes one of an alternating filter (on/off) between Null and values that may be there, as you navigate through records. If you're only going to use the textbox as a search tool and it won't be bound, then the AfterUpdate event of the textbox will need to modify the filter so as to restrict the form's records to be those that contain that value. As you navigate off that record, the original filter would need to be reinstated and applied (Current event).
An alternative is to divide into to processes. One where you open the form to satisfy the first two goals, the other to go to a specific record. That could be done via a 'process selection' type of form, or a button on the open form that will close it and reopen it to suit.
Last edited by Micron; 01-17-2018 at 10:27 AM.
Reason: spelin
The more we hear silence, the more we begin to think about our value in this universe.
Paraphrase of Professor Brian Cox.