Relation built on multikey field

[swissguy]

Hi

My FM10 Application ist separated into two Modules: the application module itself with all the tables and the data and a print module that contains all the logic und layouts for printing (list of invoices and single invoices or clientslist, among other things).

I ship runtime versions to my (few) clients.

That allows me to change printlayouts and to redistribute the printmodule (that contains no customer data) without touching the application runtime file - no hassle with re-importing the customers data.

Works well and makes life easier if change requests for printlayouts come in.

The printmodule just contains TO's to the tables in the application module. Seems like a brilliant idea. Until...

To "transmit" foundsets to the printmodule I use a (what seems to be called) global multikey-fields that is filled with the keys of the current foundset in the app module (with GetNthRecordSet) prior to the call to the print module. Here I have a relation from this multikey field to the key field in TO called foundset.

That works fine - if the user selects (by the functions that are available to him) say 5 Records out of 100 then only 5 are being printed on the list. Works as designed.

But here comes the problem: if he selects another set of records the multikey field ist again set up but this time the GTRR in the print module shows the very same set as it did for the first time around. This does not change until I restard the application - only then ist new new set recognized. In Short: it works ok, but only the first time around.

The relation to the multikey field seems not to be "updated".

No matter what I do, the foundset in the printmodule stays what it was at first use after startup.

Is there a way to force this? Is there anything that I overlooked and need to know?

Regards from Switzerland, Peter

[swissguy]

Hi again

Sorry to bother you all.... just found the solution by browsing thru some of the posts here. I inserted a Refresh Window [Flush cached join results] and that does the trick. Did not find this necessary because the print window is being closed after printing - and another one might no be opened for a long time during the users session.

Regards, Peter