When attaching a Retrieve Spec for a report, the values in the Spec Viewer contain more field specifications than in the retrieve spec.  For instance, I had a spec for only City="Calgary", but when I attach the spec I get City-"Calgary", ID="19", Name="John", etc..

Any clues?

Thanx

if i just load the retrieve spec, only the field City=Calgary is filled out and i get the correct results. However, if i attach the spec to the report and try to preview it in Search Mode, Designer freezes (i even tried waiting for >1 min)

yes it works if i don't attach the spec. i also have a sort spec attached to the same report. removing the sort spec still causes Sesame to freeze.

as an aside: is there a way to run a report w/out having to do a search? i mean, if we attach a retrieve spec to a report, it seems redundant to have to perform a search before previewing the report w/ a spec/

attaching the retrieve spec to the report causes Sesame to freeze.

not attaching the retrieve allows execution of the report minus the retrieval i would like it to do.

i guess the way around this is to perform a retrieve on its own and then generate the report?`

i tried that, and same problem

I'm not seeing any problem here. I went into Sesame Runtime and put "Calgary" in the "City" LE - I then went to the spec manager and saved that spec under a new name. I exited Runtime, went into SDesigner, opened the report "Calgary Area Report". The original attached spec had 10 LEs specified scattered across 5 subforms. I attached my new spec to the report. I exited SDesigner and ran the report in Runtime. It retrieved the "Calgary" records and generated the report immediately.

I then investigated whether the original spec (the one with 10 LE specified, "Calgary Clients") was locking up Sesame when generating a report. It isn't. It is, however taking a very long time to generate the report. This is because all of the subforms (9 of them) in this application are set to be "relational" rather than naturally linked. To do a search across 5 relationally linked subforms, these five:

Children (763)
Life Insurance (1778)
GIC (644)
Daily Interest (311)
Investments (0)

Forces Sesame to have to run through all the records in the application (10466) to find those that match the definition type (totals in parenthesis above), and run through those to find those with matching key fields, for each and every parent record. Assuming that it cannot find any matching records (the worst case, but true in the case), that amounts to:

operations = (1624 * (10466 - 1624))

or 14,359,408 operations just to determine that none of the records qualify.

If natural linking were used instead of relational for these forms, Sesame would only have to search the subrecords that actually are children of this parent record, without having to run through all the possible children to simply determine if they are *this* record's child.

Relational linking should only be used in cases where the information in the child record is likely to appear under more than one parent. In looking at your application, I would highly recommend that you change:

Children
Life Insurance
GIC
Daily Interest
LTCare
Critical Illness
Investments
and Disabilities

to be naturally rather than relationally linked. The information in these records must be unique to the individual parent record they are linked to - as indicated by unique information such as policy numbers. The Group Insurance form maybe better served as relational in that many individuals might fall under a single policy number. But for simplicity's sake, and given that the information held by Group Insurance is unlikely to be changed "standalone" - it may well also be better off as naturally linked.

Additionally, if naturally linked, you would be able to reduce the SBasic code scattered through this application very significantly, in that much of it is there to generate and maintain unique key fields. In each case I could find, these are being used to generate a condition identical to natural linking but with significantly more overhead.

There is a good summary of when to use natural and when to use relational linking on page 452 of the User's Guide.

Quote:


You would base your Report on the Client database, and include a Subreport based on the LifeInsurance database. This would get you all the Client info, plus all the child records for each Client.

BTW, you can also still store the client name in the subrecord, if you want to run reports directly against the LifeInsurance database. You just don't use any particular piece of data as the parent/child link. The link is maintained automatically.