OL Learn

Problem setting record boundaries in text files

I have a text file data source. I am trying to set a record boundary every time the customer number changes. Here are my boundary settings
It works fine on input pages that have data in the selected location - even when the data is blank (spaces). But when I have an input page that has no data in this location (the line is less than 72 characters long), the test for “on change” doesn’t seem to be done at all.
So, for instance, if I have data where this location contains
" "
I get a boundary correctly between spaces and 201111, another between 201111 and 202222. But I don’t get a boundary between 202222 and “” (empty).
I would expect the test 202222=="" to return false, so it is clear that it is not being tested. I can script the boundary test, or I could space pad every line in a pre-processor step but both seem over the top.

Well you definitely stumbled into an issue we didn’t foresee. I will report it to our development team to get it fixed, but in the meantime I’m afraid you have some scripting ahead of you.

Something like this should work, once you’ve adjusted the CreateRegion() parameters:

var myData = boundaries.get(region.createRegion(71,3,80,4));

myToken = (!myData || !myData [0]) ? "EMPTY" : myData[0];

if (boundaries.getVariable("lastData")) {

Thanks Philippe_____

They are only minor things :slightly_smiling_face:, but 2 other issues with boundary scripts - (1) changes to boundary scripts cannot be undone/redone and (2) when a boundary script is changed, the datamapper configuration does not register as changed, so the “save” option is not available, only the “save as” option.

I will create tickets for those items as well.

Note that your previous issue (blank selection not firing the onChange event) has been fixed in our code but that fix was too late to make it into the upcoming 2019.2 release. It will, however, definitely be included in the 2020.1 release.

Well waddaya know, that ticket was already reported in our system! (the undo/redo and the unavailable Save options are both linked to the Configuration’s “dirty” state, which is set incorrectly).

I just bumped up its priority as it seems like a relatively easy fix.