Snapshot release 18-Dec-2023

There is a new v1.45.1 snapshot release. Changes since the previous v1.45.1 snapshot release include:

  • changes to Calculate new operations IndexOf and LastIndexOf, including change to 1-based rather than 0-based
  • added a Quarter operation to Calculate
  • improved how Num Base guesses the base of the input data
  • when adding a Note item you can now type your comment without having to click on the comment field in the Right pane
  • fixes to bugs in the previous snapshot

You can find out more and download the release for Windows or Mac at:

Please try it and let us know if you have any issues.

If you downloaded the previous snapshot, you may need to refresh the page.

The downloads should be called:
Windows: EasyDataTransform_1_45_1_snapshot_2.exe
Mac: EasyDataTransform_1_45_1_snapshot_2.dmg


I am not sure it was there before or not, but in the latest snapshot, I have found an issue (in my opinion)

I am not sure it if is with all other transforms where you have this case sensitive option available or only in Count transform.

If I am choosing case insensitive, it should not change my original data as I am not changing it, I am just asking to count and don’t bother about the case of the text.

It is a fair point. But what do we do if we Count:


Do we return the case of the first instance of each?:


I don’t think this affects any other transforms. Unique doesn’t have a case sensitive option at present.

Yes that’s alright which ever case comes first, can be used to represent that set in case insensitive count. This will give clue that data has multiple cases in the data set, which is not easy to detect by eye balling when you have hundreds and thousands of rows.

At least with this case insensitive, I will get my correct count and if see different cases within my result set, will let me know, that data is not in consistent case.

I guess you can always Sort the data first if you care about which case is shown.

I am not looking for sort, I was just adding on that when case sensitivity is unchecked, then as you said, it should just pick up the first data case whichever it might be and when it gives me the count, I will have single count for no matter whatever the case data might be in.

While not changing the case in the result set (as it is doing now), I was saying that if I see, multiple cases in my result set, will indicate that my data does not have consistent case (which let say I was assuming it will have or let say should have), so by seeing different cases, I can report back to concerned party and let them know about this, so that they can fix at their end.

Understood, but using the case of the first row encountered means that:


Will return:




Will return:


If you care which one you get, you could Sort the data before the Count.



Will return consistent upper case, even the input data case is mixed.

Ok got it, your point of view about sort.

But as I said, I am not expecting case change in the first place in whatever column I am interested in and if I see different cases, then I should raise a flag and get it corrected.

Let say if I was expecting only Capital or First letter Capital and not all values are in the same case, then that should be flagged and checked why and how this data got in.

Ofcourse, for example, in all capital data, there are few lines which has different case, but if first data that is encountered was all capital, it will not show up and might go unnoticed, so for now on after seeing this, I might do count in both cases, once with case sensitivity turned on and turned off to make sure data is in expected case.

This shows it preserving the first case found.

Drill down still shows the original case.

So have you fixed it already? because when I posted, if I set the case sensitivity to off, it turns all the data to small characters in the result set and not likes yours where it is showing Capital letters as well…

Only in the local development version. I’m working on it now.

1 Like

Is there something I can do for you to make the indexOf() to be consistent like Java, where it returns the position if string found and if not returns -1 whatever the case might be, first value empty, second value empty or both first and second value empty, I will take zero in place of -1 if you prefer zero.

I’ve already spent far too much time on that! If you don’t like it, then can use use a Javascript transport and roll your own.

I am just not able to understand, why you changed your initial position in which you said so yourself, that if string found it will return the position otherwise -1 and that otherwise included all scenario that is opposite to not found.

However it shouldn’t be hard to add to Calculate 2 extra operations:

  • indexOf - Returns the index position of the first occurrence of the string2 in string1. Returns -1 if string2 is not found.
  • lastIndexOf - Returns the index position of the last occurrence of the string2 in string1. Returns -1 if string2 is not found.

Which was simple.

And since you are already doing a change, I thought I try one more time and you make this change too (no harm in hoping right).

That ship has sailed!

True, but now we are currently in new build, so new ship and new hope :slight_smile:

This is fixed in the latest snapshot: