In most cases (there are exceptions), the "best practice" recommendation it not to attach retrieve specs to a report. (Sort specs, yes -- retrieve specs, no.) This way you can always use the same report with different records.
There are various ways to print a report using some search criteria that you have saved somewhere, other than being attached directly to the report itself. Here are some examples:
1. You can use a saved retrieve spec (which is easily modified and re-saved, if needed) to get the result set, then run the report after that result set is displayed.
2. You can use a command button, located on any form, that uses the XResultSet family of commands to run reports on any database -- even one in another Sesame application with a different file name, that's not even open. You have complete control via programming to have this command button read any stored search criteria from: a database, a GlobalValue, a ClientLocalValue, a popup calendar, user input, etc.
Here's a real world working example of option 2.
var vAnswer as String
var vRS as Int
var vReportFileName as String
// Display Calendar
vAnswer = @Calendar(@Date, "Pick START DATE for Report - Esc to cancel")
If not @Error
{
// Build date range specs to be used in XResultSetSearch below
vAnswer = vAnswer + ".."
// Get result set
vRS = @XResultSetSearch(@Fn, "Invoice!Details", 0, 2, "!Date1=" + vAnswer)
If vRS > -1
{
// Run report
vReportFileName = @XResultSetPrintReport("Daily Revenue", vRS, 1)
// Close result set
XResultSetClose(vRS)
}
}