Have you timed this? Are you certain it is faster? Why are you changing the RecordSource? Could you use a query with criteria that is provided by another form? For example, select a customerID on formA and then open formB showing the selected customer? I need to know more about what you are trying to do before offering a firm solution. I do have a couple of forms where I replace the RecordSource so I can apply criteria. Filters only work if your form is based on a table or an unqualified query. Since my apps are usually linked to non-Jet back ends, this is generally poor practice since the form just sits there sucking data over the network until it has downloaded every record in the form's RecordSource. Therefore, to give the user filtering options, I build SQL strings in code (when the criteria is complicated) and then replace the form's RecordSource. When the criteria is simpler or only involves a couple of fields, I just use parameters to supply the criteria values at runtime (this is the most efficient method). In this case, the default RecordSource selects a row with the PK = -1 which returns nothing. The user selects his filters, the code builds the SQL string and replaces the RecordSource. BTW, this is the ONLY time I use embedded SQL (which itself causes bloat). In all other cases I use saved querydefs or queries saved directly in the RecordSource since they are more efficient.
To answer your bloating question, the answer is yes. Deleting a table and recreating it or deleting all the rows and appending different ones have similar effects. Access cannot recover the space used by the previously stored records until the db is compacted. If you do it a few times while the db is open and there are not a lot of rows involved., you probably won't see much bloat but if you do it a hundred times, you will see the bloat. You will need to set the FE to compact on close if you use this technique.
When my criteria is compound but simple (multiple optional fields connected by AND), I usually build a querydef that just takes parameters. Here is a simplistic example.
Select ... From ...
Where (FldA = Forms!myForm!FldA or Forms!myForm!FldA Is Null) AND (FldB = Forms!myForm!FldB or Forms!myForm!FldB Is Null) AND (FldC = Forms!myForm!FldC or Forms!myForm!FldC Is Null) AND (FldD = Forms!myForm!FldD or Forms!myForm!FldD Is Null) AND ...
Notice how the parentheses are used in the above Where statement. Since the criteria includes both AND and OR, you MUST use parentheses so that the criteria will be evaluated correctly. The OR's are used to allow the criteria to be optional so the user can specify (A and D) or C or (B and D), etc. Whatever. If you want to require one or more criteria to ensure that the user doesn't select all the records, add a final AND clause similar to the following:
(IIf(IsNull(Forms!myForm!FldA), 0, 1) + IIf(IsNull(Forms!myForm!FldB), 0, 1) + IIf(IsNull(Forms!myForm!FldC), 0, 1) + IIf(IsNull(Forms!myForm!FldD), 0, 1) >= 1)