When writing the 2nd edition I ran into this issue and reported it on the BC yammer group as following (on April 23, 2021 at 11:55 AM):
Has there been a change in the implementation of the FindRow method in Library - Report Dataset?
I am asking as I was using the return value to verify if the relative offset between two columns in my dataset was changed. In my book it did that like this:
local procedure VerifyCustomerWithLookupValueOnCustomerListReport(No: Code[20]; LookupValueCode: Code[10])
var
Row: array[2] of Integer;
begin
Row[1] := LibraryReportDataset.FindRow('Customer_No_', No);
Row[2] := LibraryReportDataset.FindRow('Customer_Lookup_Value_Code', LookupValueCode);
Assert.AreEqual(13, Row[2] - Row[1], 'Delta between columns Customer_No_ and Customer_Lookup_Value_Code')
end;
This worked as a charm. Now that I am working on the second edition and run this code on BC18 Row[1] and Row[2] always get the value 0 assigned, so, the AreEqual errors.
In the last (almost) two years I did not take the time to dive into this only to pick it up again today, writing:
Testing reports hasn't been a focus to me in the recent past, only as part of the training I provide. And the workaround has been to not check the row offsett between tags in the XML formatted dataset. For example (see also test example 8 in chapter 8 of my book):
local procedure VerifyCustomerWithLookupValueOnCustomerListReport(No: Code[20]; LookupValueCode: Code[10])
begin
LibraryReportDataset.AssertElementWithValueExists('Customer__No__', No);
LibraryReportDataset.AssertElementWithValueExists('Customer_Lookup_Value_Code', LookupValueCode);
end;
The major flaw in this approach is that I do/can not test the relation between the two tags, i.e. Customer__No__ and Customer_Lookup_Value_Code. They could be in the dataset, but unrelated. So, the workaround is a not very robust approach. I would rather tests like above (the initial code example).
Contrary to my intial statement it appears that Row[1] and Row[2] are found, but have the same value, in my case 66.
- 66, because my test creates a new customer with No. starting with GL (the no. series from MS tests library) and that will be in place 66 of Cronus customers
- so the delta between the two is 0
But on BC14 (just retested it) Row[1] and Row[2] are not the same. In my example Row[1] = 3 and Row[2] = 16, making the delta between the two 13
But on BC18 and beyond (and maybe also on BC15 and higher) row is apparently not the meaning of row in BC14.
- It seems like on BC18 row is the row in the dataset which holds a record context
- Where on BC14 each element (field) has its own row
So, on BC 18 I should not tests on a delta of 13, but a delta of 0 to be sure that am checking two related tags, i.e. two fields of the same record.
When writing the 2nd edition I ran into this issue and reported it on the BC yammer group as following (on April 23, 2021 at 11:55 AM):
Has there been a change in the implementation of the
FindRowmethod inLibrary - Report Dataset?I am asking as I was using the return value to verify if the relative offset between two columns in my dataset was changed. In my book it did that like this:
This worked as a charm. Now that I am working on the second edition and run this code on BC18
Row[1]andRow[2]always get the value 0 assigned, so, the AreEqual errors.In the last (almost) two years I did not take the time to dive into this only to pick it up again today, writing:
Testing reports hasn't been a focus to me in the recent past, only as part of the training I provide. And the workaround has been to not check the row offsett between tags in the XML formatted dataset. For example (see also test example 8 in chapter 8 of my book):
The major flaw in this approach is that I do/can not test the relation between the two tags, i.e.
Customer__No__andCustomer_Lookup_Value_Code. They could be in the dataset, but unrelated. So, the workaround is a not very robust approach. I would rather tests like above (the initial code example).Contrary to my intial statement it appears that
Row[1]andRow[2]are found, but have the same value, in my case 66.But on BC14 (just retested it)
Row[1]andRow[2]are not the same. In my exampleRow[1] = 3andRow[2] = 16, making the delta between the two 13But on BC18 and beyond (and maybe also on BC15 and higher) row is apparently not the meaning of row in BC14.
So, on BC 18 I should not tests on a delta of 13, but a delta of 0 to be sure that am checking two related tags, i.e. two fields of the same record.