You will have to give me some details of how you want it to work. For example, does the user start from a form where he/she selects the vendor, start, stop dates, and a report is built. In my roster example I start with a form with a tree view. The user checks the units he wants. When he closes the form it prompts him if he wants to save the roster. He gives the roster a unique name, and the unit primary key are saved to a table (tblImportExport). When they open the application the user is prompted if they want to open a saved roster. They pick the roster name, and I read through the table checking the treeview with the appropriate units.
I also need relevant table names, and names of fields that are the primary keys and foriegn keys. Depending on your buisness model, it may not make sense to save the parameters of the query that define an inventory. You may need to save primary keys. For example lets say an invoice is uniquely defined by a vendor, start date, and end date. If after the invoice goes out someone tries to cover their butt after the fact by adding a record that meets this criteria. Then it would appear as if it was part of the invoice next time I load the query. It is dynamic so there is no real "history". If you save the primary keys of the relevant tables instead of parameters of a query, you would have a real "snapshot" in time. If you go with primary keys instead of paramaters the table will grow very quickly, but it is only primary keys. Instead of one record per invoice, you will have a record in this table for each record in your invoice.
Provide the details. I can help you with the solution. I think either one of these is a correct approach.
A modification of the first approach is to save the actual sql string that makes up the invoice instead of the parameters in the invoice table. So all you have is two columns:
tblInvoice
autoInvoiceID
strInvoiceSQL