Access to fields from outside the report container in databound mode

I would like to know if it is possible to access fields in a report container from outside that container. E.g. a customer/order report where customer table is passed as variables and orders as fields. I can access the customer data from outside the report container if automastermode is set for the customer table.

I would like to create a header similar to “customer x, first order is order n”, but when I add a reference to the order no field, it does not show

That’s another sophisticated request :wink: . In order to access the first order, LL would need access to it during the drawing of the header information. For performance reasons however the providers usually don’t pass real data before actually printing it. Thus - a typical catch22 situation.

A possible workaround to make this work is a combination of GetVar and SetVar and a linked object.

First, in your data line definition, change the column you’d like to access (in my sample it’s the item number) to read

If (Count(1, false)=1, SetVar("FirstItemNumber",Item.ItemNo), Item.ItemNo)

What this does is for the first record setting the “FirstItemNumber” variable to the ItemNo field and printing it, in all other cases just printing the field. Thus, after printing the first line, you can access the item number in a formula like this:

"Customer "+Customer.Company+", first item is "+GetVar("FirstItemNumber")

In order to make sure the printing order is as required, you need to link your text field to the report container. I’m attaching a sample showing the concept here (Invoice sample for the DemoApplication24). Invoice.inv (147.7 KB)

Hi Jochen, thanks for your reply and suggestions. So the answer to my initial question would be “No” (not by default).

I did not try your suggestion as I am looking for a more generic solution and I think I have come up with a more generic approach (at least for my situation where I am coming from a non-databound flat table).

In order to use the databound feature, I already needed a “parent” table because I needed ResetProjectState() functionality to be triggered by the AutoMasterMode functionalty. So at first I added a simple static parent table “Document” within only 1 field (DocumentID) which I also added to the definition of my “flat” child table. The the code would create a Document record whenever a ResetProjectState was indicated in the Child table.

So I simply changed the code, so that the Document table becomes a dynamic table instead of a static one. This allows me to add all the fields from the “child” table to the Document table. Now whenever I create a Document record, I also copy the fields from the first child record to the corresponding fields in the Document table. This way, I can reference any of the values in the first record from outside the report container. No need for any linking.

Do you see any drawbacks on this approach?

Hi Jos, sounds good enough, too. As long as the data is filled reliably, there shouldn’t be any unexpected side effects.