Further Restrictions on Relations?

Stimulsoft Dashboards.BLAZOR discussion
Post Reply
luloah
Posts: 3
Joined: Thu Jul 21, 2022 4:26 pm

Further Restrictions on Relations?

Post by luloah »

Hi,

I am evaluating your product but unfortunately, I struggle using the Relations in a Master-Detail setup (a crucial feature for us).

What happens without Relations?
Both tables print their complete data set.

What happens after adding the Relations (string-based columns)?
The column headers of the detail tables are printed, and the number of times equals the row count of the master table.

Is it possible, there are further restrictions on the column which can be used for the relationship?
(i.e. has to be an id, and not just a simple string, although unique in the master table)

Any pointers are appreciated.

Kind regards,
Luloah

Setup in a nutshell:
- New Datasources added as Objects (Data from business objects).
- Data handed over in Blazor code using RegData().
- Report - apart from datasource type and data itself - practically identical to Stimulsoft's example "TableInvoiceWithGroups"
- Type of ElementCode in master table:

Code: Select all

<value>ORIGINAL,ElementCode,ElementCode,ElementCode,System.String,daae070ede27402dafdf11c92c5b4b43</value>
- Type of ElementCode in detail table:

Code: Select all

<value>ORIGINAL,ElementCode,ElementCode,ElementCode,System.String,_x0033_fd2344f5fb344ef939b2edfccdf23a7</value>
- Relations definition:

Code: Select all

<Relations isList="true" count="1">
      <ElementResult Ref="13" type="DataRelation" isKey="true">
        <Alias>ElementResult</Alias>
        <ChildColumns isList="true" count="1">
          <value>ElementCode</value>
        </ChildColumns>
        <ChildSource isRef="11" />
        <Dictionary isRef="1" />
        <Key>baf0271272b249fbbb42f3a6f5cb5aa8</Key>
        <Name>ElementResult</Name>
        <NameInSource>ElementResult</NameInSource>
        <ParentColumns isList="true" count="1">
          <value>ElementCode</value>
        </ParentColumns>
        <ParentSource isRef="12" />
      </ElementResult>
    </Relations>
Lech Kulikowski
Posts: 4969
Joined: Tue Mar 20, 2018 5:34 am

Re: Further Restrictions on Relations?

Post by Lech Kulikowski »

Hello,

Please send us a sample that reproduces the issue for analysis.

Thank you.
luloah
Posts: 3
Joined: Thu Jul 21, 2022 4:26 pm

Re: Further Restrictions on Relations?

Post by luloah »

Hello,

It was just a simple question (i.e. no need to invest time creating a sample):

- Is it possible, there are further restrictions on the column which can be used for the relationship?

Thank you.
Lech Kulikowski
Posts: 4969
Joined: Tue Mar 20, 2018 5:34 am

Re: Further Restrictions on Relations?

Post by Lech Kulikowski »

Hello,

> - Is it possible, there are further restrictions on the column which can be used for the relationship?

It should be of the same type.

Thank you.
luloah
Posts: 3
Joined: Thu Jul 21, 2022 4:26 pm

Re: Further Restrictions on Relations?

Post by luloah »

Thank you for your reply. As you can see in the code extract above, this is the case and should not cause a problem.

However, my question was, whether there are Further restrictions (i.e. not mentioned in the manual).

For example, the manual states, it should be the same number. Now, does that mean, it cannot be a string, hence my problem?

***
Extract from the manual (https://www.stimulsoft.com/en/documenta ... er-manual/):
Fields shows the master and child data column-keys, which set the Relation between data sources. Column-keys should comply with all rules of creation relations in ADO.NET:
1 It should be the same number of them;
2 Their types should match, if the master column-key of the String type, then the child column-key should be of the String type;
3 And so on;).
Lech Kulikowski
Posts: 4969
Joined: Tue Mar 20, 2018 5:34 am

Re: Further Restrictions on Relations?

Post by Lech Kulikowski »

Hello,

No, there are no further restrictions.

Thank you.
Post Reply