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)
	}
}