I'm going to answer some of your last questions first...

Quote:


It sounds like you started printing a "result set" that contained a large number of records.  If this was the entire ZipCode file, that was over 43,000 records!

Sesame performs its actions on a "result set" (the records retrieved based upon some search criteria.  These criteria could be some that you entered, or in the case of a report that is already designed, some search criteria that was stored as part of the report.

In the User Guide, pp369-370 it discusses that specs can be attached to a report.  Attached specs take precedence over any retrieve or sort spec you used to get your current result set.  You must be careful when attaching specs - to be able to get the results you want.  It might be best to leave the specs blank in reports so that the report will act on your result set, until you are confident in attaching specs.

You are correct.  You must go to SDesigner, design your report, save it, and reconcile.  Then you can run your report from Sesame.  You can Preview what you design in SDesigner before reconciling - to see if what you have set up is what you want.  When you are doing this you are working with a "copy" of the application and its records - not the "live data".  Having to go from Sesame to Designer, and back may seem like a lot of extra steps - but the power and flexibility to work, design and test design changes, and not interrupt other workers on a network is a tremendous benefit.

If you want to run "quick reports", you should design these without any saved specs - so that you have the flexibility to generate the "result set" of records that you want.  Sesame allows more freedom in that you can generate a result set, and then manipulate that result set (changing retrieve specs for instance to remove a few unwanted records).  Once you have the result set you need - you generate your report.  In Q&A you had to start over, modify the retrieve and sort specs and re-run the report.

I hope this has helped some.  I'm not proficient with Sesame yet - so I hope I didn't make any major errors in my comments.  Sesame is not "Q&A version 6", so it takes a good bit of re-thinking to adapt to the way Sesame works.  In my opinion, Sesame was envisioned and developed to be a product that would allow Q&A users to have a program that would allow them to salvage their data and transition smoothly to a new software package.  Sesame retains much of the programming syntax from Q&A, and so makes the transition less painful - BUT has tremendous power that Q&A lacked.