Strategy for handling two separate queries/recordsets in Access

I'm looking for input as to how to best implement some required business functionality in MS Access.  (Environment details below)

From a form, a user needs to browse and edit rows in a table. There are two modes they can operate in:  1. Browse ALL, and 2. Browse Unprocessed (or "raw").

While in Browse ALL,  all rows are visible. Any row can be edited and updates saved.  When saved, userid and date/timestamp are saved into two columns of the row (USER_SAVE, and SAVE_DT). If the table has 100 rows, all 100 are visible and available for update.

In Browse Unprocessed mode, only a subset of the data is visible and available .. only those rows which have not been edited and saved before (i.e. USER_SAVE and SAVE_DT both NULL).

Users switch between these modes via radio buttons on the form.  When they switch, the following must occur:

1. switching from Browse Unprocessed to Browse ALL - the position within the table remains the same, i.e. if row ID=32546 was the current record in Browse Unprocessed mode, it will remain the current row once switched to Browse ALL mode.

2. switching from Browse ALL to Browse Unprocessed - if the current row is Unprocessed, it remains the current row after the switch.  If the current row has been processed, then the next unprocessed row will become the current row, i.e. current row ID=32544 has been processed, and so has ID=32545, while ID=32546 has not been processed.  When the mode is switched, row ID=32546 should become the current row.

Those are the business requirements. Here are the approaches/strategies I've considered and toyed with.  My inexperience with MS Access leaves me not knowing what approach is best suited.  Considerations are ..

I created the form with Access GUI, so fields were bound to the underlying recordset, which was handled under the covers by Access.  I was uncertain how to create the subset of rows needed for the Browse Unprocessed mode.

One approach was to apply a filter to create the subset.
   

 sSQL = "([USER_EDIT] IS NULL) AND ([USER_SAVE] IS NULL)"
    DoCmd.ApplyFilter whereCondition:=sSQL

Select allOpen in new window

(I know this isn't applied to the recordset, because setting rst.Filter only takes effect for a second recordset that's created from the first with Filter defined. The question is, what object is the ApplyFilter method invoked on?)

Another approach would be to create two separate recordsets, one which queries all the rows and a second with a WHERE clause to select only unprocessed rows, then swap them when the mode changes. Swapping is done by changing the form.Recordset attribute.  When I tried this, the datasheet view showed the row selection worked properly, but the first row was always made the current row.  I even used the FindFirst method to position the cursor, but it didn't work (..or it did work, but then was overridden by something else..)  When I tried this, the binding of the fields to the recordset seemed to be affected, and I'm not sure how to rebind them, or if it's even possible.  As a result, the events associated with the fields were affected and bizarre behaviors appeared.

Another possible approach would be to use only one recordset, but change the RecordSource queries .. one to select all rows, the other select with WHERE clause for unprocessed rows only.  I haven't tried this yet, but it seems promising.

Before I venture out on that path, I would like some input from the Experts.  Please let me know your take on the viability of these approaches, and suggest others which I haven't explored.  It's very possible that there is a simple approach that I'm not aware of.  

All suggestions and analysis of approaches is most appreciated.
At this point, I'm all ears.

Environment:

Using Access 2007, with libraries for DAO:
 - Microsoft Office 12.0 Access database engine Object Library
 - Microsoft Jet and Replication Objects 2.6 Library

NOTE: For development, I'm running this against a local Access database.  For production, it must run against a remote SQL Server database.  I recall some citations along the way that stated there would be some limitations for some database connections.