I can't seem to find the post now, but the other day Erika said that once a spec is attached to a report it is saved with the report and can be removed from the saved specs in spec manager.  I hope my understanding of that is correct.  If so, I have a few questions.

If the spec as saved in Spec Manager is later revised using different criteria, my feeling is that this revision would not be carried along to the report that was using it.  Is that right?  If so, what would be the method to update the report with the new criteria?  Detach and re-attach the spec?  Or is there a quick & dirty method to tell my reports "use the updated spec" in one swell foop?

My Invoice database has a large number of saved reports (over 3 dozen and growing).  Many use the same retrieve and/or sort specs, so if a spec was revised and the detach/re-attach method is necessary, I would have quite a bit of work to do, even in just tracking down the ones I need to modify.  Is there a way to get a list of the specs that are attached to the reports?  I remember using some utilities a while back, on Version 1, which gave me a printout of all my form's elements and their attributes.  Does such a utility exist for reports?

Great question Scott!

Horrible answer!  I am sure that I never heard of this before.  Major rethinking, design, and training impacts.  Is there a "where used" list that can list the reports that are using a particular Saved Spec.

What I am hearing here is if a Saved Spec for Retrieval/Sort is modified, then you must go through all reports in that database, check to see if the spec was used, and if YES, then it must be removed, reattached, and then reconciled to the database again.  Users cannot change report specs without access to designer vs. just changing a Saved Spec.

I guess the solution may be to name Saved Specs with a prefix if it is used on a report.  Users should not be allowed to change any specs that start with the special prefixes, which means using programmed pick lists for Retrieve/Sort specs, and disabling the ones that show in the normal Saved Specs list.

Another solution would be to keep a database of Reports and the names of Saved Specs that are attached.  Now you can use that database to make the "where used" list that I asked about earlier.

If not in the manuals, this should be noted very explicitly with the next issue.
Aaargh, maybe I am over reacting, need some time to settle down.  This was a major surprise.

I think the correct method should be that the Spec attached to the report should be changeable by the user, and the report should be affected.  A warning message could come up warning the impact on a list of specific reports, providing the option to continue, or save as a new name before modification and/or deletion.

Quote:

I achieve an effect similar to this by using @LoadRetrieveSpec() and @LoadSortSpec().

All my reports are initiated from a custom main menu. Each report has a command button, which sets a GlobalValue flag, opens the correct form in search mode, loads the retrieve and sort specs, gets the results, then runs the report.

This way, I can simply make changes to the saved spec, and it is used when my report is run. (The process also asks me if I want to make any "temporary changes" to the retrieve specs each time the report is run.)

Bob_Hansen wrote on Sep 19^th, 2007 at 12:57am:

Yes, you remember correctly. But, I just don't attach any retrieve specs to reports (there are a few exceptions). Though, I usually do attach sort specs.

Quote:

Yeah, a little flag went off in my head when Erika mentioned the report/saved spec disassociation.  As you know, my project is in a tumultuous period right now, and I've got requests for changes coming at me from every direction.  My Invoice reports in particular are being changed left and right, and it occurred to me that what if, suddenly, the boss wanted everything sorted in the opposite direction, or something like that?  Yikes.

Carl's idea of loading a spec on the fly is definitely something I need to look into.

I've found that one thing that makes this much easier to manage is to have fewer reports. This is one of the things that not attaching retrieve specs can provide.

The complaints you have about having to find and reattach many specs also applies to having to add/delete an element or change a column header or change a calculation. If you have a bunch of copies of what is essentially the same invoice report, changes become a hassle.

If you have one invoice report which does not have an attached retrieve, and you use any one of the various methods available to run it against the records for this month, last month, last year, etc. then you have only one report to maintain instead of a dozen.

There are always several options for approaching any given problem, but this one has worked very well for me, so I thought I'd share it with you, in case you might find it useful.

Inside Sesame subscribers will find an article about this technique (running one report with multiple saved retrieve specs) in the November 2005 edition of Inside Sesame (page 1). The article is named "Why make 10 reports when one will do?".

Those who would like an attached report retrieve spec to be dynamically linked to the saved retrieve spec should bear in mind that retrieve specs can be modified and saved by users, so you could not reliably run report XYZ with predictable results - a very unsatisfactory situation.
Furthermore, saved retrieve specs are stored in the DB file, not the DSR, and this would cause uncertainties in a scenario where updated DSRs are reconciled.