I was looking for info or a fix for this bug in Kinetic version 2025.2.x but didn’t find anything in my brief search, so I debugged the issue and put together a working fix. Thought I would share it in case someone else runs into this.
The situation is this:
Say you have a Panel Card Grid in a kinetic app which is fed by a Provider Model → BAQ ID.
Say that BAQ has one or more Date columns in the Grid → Columns list.
Say a user wants to set the Date Column’s Filter to “Is Null” (is empty - no date value) or “Is Not Null” (is not empty - has date value).
What’s that? No results? But you know there are rows in the BAQ’s data with blank values and rows with non-blank values in this Date column, you were just looking at them next to each other before you tried the column filter…
First mistake- you thought a Kinetic Grid element, and its associated features, would work as expected.
So next you opened up your browser dev tools to look at the Network log, and you see that the ExecuteBaq rest call resulted in a non-descript, uninformative BAQ Execution Error when you tried to change any Date column’s filter to “Is Null” or “Is Not Null”.
You realize this issue effects all of the hundreds of custom dashboards and apps you have built that may contain a BAQ with a Date Column that users expect to use grid filters on for “Is Null” and “Is Not Null”.
How do you fix it? Well, the following appears to work quite well for now, at least in 2025.2.x (YMMV depending on version and other customizations in your system):
If you inspect the Payload for the failing ExecuteBaq REST calls in the browser Dev Tools → Network Log, you notice that the offending Where clause(s) contain an odd appendage- “... IS NNULL...”, or " not ( ... IS NNULL)...".
Why is it odd? Well it looked odd to me because usually in SQL statements inside a Where Clause you would type “IS NULL” with ONE “N” in the word “NULL”, not two. NULL being a standard SQL Keyword which requires no conversion.
Ok ok… maybe this is actually correct and Kinetic is adding the extra letter ‘N’ to the word ‘NULL’ for some totally legitimate and valid reason…
No! - It’s not legit. It’s a bug shipped in the default Kinetic system effecting Grids fed by Provider Model BAQ’s.
Side note- as far as I can tell the extra ‘N’ is an artifact of how Kinetic is building the Where Clause statement, because I can see the ‘N’ in front of other elements like string elements ("… N’some value’ …) where it works normally turning those into nvarchar. Most likely the same step that adds N in front of text values treats the NULL keyword in a date-column null check as a value and prefixes it too. NULL is a keyword, not text, so it must never get an N, and SQL Server rejects NNULL as a syntax error. I confirmed that the shared filter builder emits a clean IS NULL
I fixed this in our system by putting a Pre-Processing Method Directive in place to fix the erroneous Where Clause strings before the server processes it:
Method: Ice.BO.KineticErp.ExecuteBaq()
Add a Pre-Processing Directive, with a single Execute Code action
Add the following code:
// Workaround: Kinetic 2025.2 client bug. BAQ-provider grid column filters "Is null" /
// "Is not null" on Date/DateTime columns send "IS NNULL" / "not ... (...IS NNULL)" in the Where
// execution setting, which fails SQL parsing. Retest and remove (if needed) after each Kinetic upgrade.
if (this.executionParams == null) return;
foreach (var execParam in this.executionParams)
{
if (execParam?.ExecutionSetting == null) continue;
foreach (var execSet in execParam.ExecutionSetting)
{
if (!string.Equals(execSet.Name, "Where", StringComparison.OrdinalIgnoreCase))
continue;
string value = execSet.Value?.ToString();
if (string.IsNullOrEmpty(value) || value.IndexOf("NNULL", StringComparison.OrdinalIgnoreCase) < 0)
continue;
execSet.Value = System.Text.RegularExpressions.Regex.Replace(
value,
@"\bIS(\s+NOT)?\s+NNULL\b",
"IS$1 NULL",
System.Text.RegularExpressions.RegexOptions.IgnoreCase);
}
}
What the code does:
Loops the execution parameters and execution settings being sent to the ExecuteBaq method, searching for the “Where” clause item.
Replaces the erroneous “IS NNULL” text with “IS NULL”
Seems to work like a charm but I would be mindful that the original bug could get fixed in future versions.
Note that this version of the code is a little bit overkill using RegEx to fix the strings where as you could easily do the same using simple String.Replace() methods. I tested this originally and it also worked great.
I hope this helps someone else out there. Maybe this is fixed in 2026- I’ll find out soon enough, but until then I need my grids to filter date columns correctly for my end users, so a BPM patch will have to suffice.
No I haven’t quite yet, will get around to it eventually- They had a problem case from years ago for this, PRB0276640, but they reported it as resolved. Looks like they fixed the other date column filter behaviors years ago and overlooked these 2 somehow.
Epicor support said they were not able to reproduce the error on their end- so it might potentially be something unique to our version / environment / server, not sure. We have a lot of issues unique to our cloud server, this may be another one for all I know. I am curious if other users could test this in their kinetic environment and see on their end if they run into the same issue.
To test it, the grid element needs to be fed data by a BAQ in the Provider Model.
They never seem to be able to reproduce errors on their end so it must be the users fault. So convenient for them. Crazy how we all seem to have the same something unique to our version / environment / server causing these issues.
I think the only realistic hope for date sorting is ISO8601. Casting dates to date for sorting would be unexpected in this context. Strong typing throws unit testing errors without a little handling nuance, and sometimes unit testing is treated as a performance target instead of a guiding metric.
null can be handled correctly, but I wouldn’t trust their solution to correctly differentiate the literal text, “null”. For example…
I mean, sorting dates is really easy… Its literally an out of the box functionality of Javascript.
I really dont understand a lot of the issues the Epicor team is having with moving to a web browser considering how many of the issues they have are problems that have been resolved 20 years ago and have clear cut best standard practices and implementations.
True, but does require casting data to date. Then unit testing tosses a lizard in the date field and if content and typecast handling don’t handle incompatible data it’ll fail the unit test.
In a perfect world, a developer is able to responsively depend on unit testing to iterate towards a robust product.
But sometimes, “failed unit tests” is naively applied as a performance expectation and developers follow the incentive, avoiding unit testable functionality.
Which tends to produce the kind of workplace that accrues developers inclined to say out loud in public that bubblesort is an advanced algorithm they regularly use to improve performance.
ok… you diagnosed this correctly… it is a bug. There is also another bug report that is semi-related (but different) where if you filter a column (non-date) for nulls, and then try to export the data to excel, the export crashes.
BUT since this is different, I would ask that you please submit a case.
NOTE that we have an internal initiative to improve grids. The number of grid bugs had (as you know) gotten out of hand, and we needed to put a special task force on remediation of those bugs. Our development team hopes to have the vast majority of the issues resolved and in QA by tomorrow… But since there were so many, sometimes when new issues were reported, they got lost in the clutter.
I did a search in the tickets for the word “NNULL” and only found the one semi-related ticket… so… like i said before, please report your specific case, and this may help us burn down even more Grid Performance issues.
Thank you
Good to hear this actually happened. I got several PRB notifications over the last few days on grid bugs so that explains it. Some have mentioned the bug is fixed in ver12.2.200 but does that mean 2027.100 since 2026.100 is 12.2.100?
@Randy the grid fixes are being applied as soon as possible.. but some (sorry to say) are breaking changes, which will require the fix to wait until 2027.100… but whatever can be brought back to earlier monthly releases will be.
There are some framework changes that are being done in 2027.100 that will greatly enhance grid performance. One big concern WAS to make sure that when we do the changes, that it doesn’t affect your customizations. The designers are taking that all into their design, and so far, as I have observed, you all should be very happy with the new grid performance AND you should not loose your customizations.
It was not my intention to turn this thread into such a large topic! But thank you all for chiming in with your thoughts and comments, and thanks @timshuwy for the promising words. Looking forward to seeing those changes and improvements eventually in Kinetic.
I hope the temporary fix I posted in the original topic doesn’t get lost in the noise It is a simple enough fix, so not the end of the world!
I also “discovered” a bug with null value when I created a rule. I worked with support and they were able to reproduce and passed along to tools dev for addressing.
It is a simple enough fix, so not the end of the world!