Change in DataView column types with new update?

Kinetic ERP
,
1

I have an app that I created to help users view any Pick Lists that are available to be printed, and it includes a button that will print the SO Pick List to a network printer. The recent update broke it.

The Epicor function takes the DataView from App Studio as a System.Data.DataSet parameter. previously, the below code worked:

    foreach ( DataRow r in DashboardDV.Tables[0].Rows )
    {
        bool Selected = (bool)r["Calculated_Select"];
        if (!Selected) continue;
        
        iOrderNum = Convert.ToInt32((double)r["OrderRel_OrderNum"]);

        PrintOrders.Add( iOrderNum );
    }

Starting today, however, my users are getting an unhelpful “Correlation ID” error every time they use it. I looked up the guid, and it was throwing an Invalid Cast Error:

Unable to cast object of type 'System.Decimal' to type 'System.Double'.

So I changed the code in my function to:

    foreach ( DataRow r in DashboardDV.Tables[0].Rows )
    {
        bool Selected = (bool)r["Calculated_Select"];
        if (!Selected) continue;
        
        iOrderNum = Convert.ToInt32((decimal)r["OrderRel_OrderNum"]);

        PrintOrders.Add( iOrderNum );
    }

and voila, it works. I remember this issue when I was building the thing, as it absolutely HAD to be cast as a double in order to function (I was initially just trying to cast as Int32, without the Convert.ToInt32() bit).

Just a heads up in case anyone else runs into Functions that mysteriously stopped working.

2

Same, I had a function I ran into a new double ↔ decimal cast issue.

It was moving from 2025.2.10 → 2025.2.16. Sounds like a Schema change occurred in a dot release…

3

Peace Out No GIF by DreamWorks Animation

4

Same here.

5

Me three. Gotta love those secret changes.

6

I have this same issue when parsing in a dataset in C# functions

for example, to parse the length value in an incoming table

this.items.Tables[INPUT_TABLENAME]
	.AsEnumerable()
	.Select(fn => new {
	Length = Convert.ToDecimal(fn.Field<double?>("Length") ?? 0)
});

becomes

this.items.Tables[INPUT_TABLENAME]
	.AsEnumerable()
	.Select(fn => new {
	Length = Convert.ToDecimal(fn["Length"] ?? 0)
});

where just ignoring the source type seems to fix it, even if they keep flip-flopping

7

First My apologies on behalf of my team and I. This should have been flagged as a SIC (software interface change) and called out as such and that we would not then have allowed an update with this fix to be applied.

it is from the resolution of problem: PRB0308432

it is a deserialization change on the server for how inbound numbers are dealt with.

Back in 11.3.200 a fix went in for this issue for functions for PRB0273273 but it was only for functions. The exact same issue arose for Updatable BAQs in the first problem I mentioned.

The basic issue being dealt with is that json deserialization determines what value a column should have by the value of the first row. So if for a particular numeric column the first row has 100 - it will be an integer as far as the deserializer is concerned. so if the second row comin gup was 15.123 it would deserialize as 15 and the decimals would be lost.

So we needed to take this fix broader when we are deserializing data that isn’t going into a structured already typed object like a table set. While doing so we were also aware of other customers reporting an issue that making them all double was causing them to lose data on really precise numbers with decimal digits.

Research showed that the decimal data type would better support their needs as well as the needs for this request. So what you are running into is that for unstructured data in functions (which previously forced them to double are now forced ot decimal) as you can tell the impact is specifically to functions bring up numeric data that isn’t going into a strongly typed tableset.

8

Thanks for bringing a little bit of the old Epicor back and sharing some info @pferrington ! :partying_face:

(ps can you convice whoever is in charge of the epicor status page to do the same? :pleading_face:)

9

Slightly off-topic but related.

Default behavior for deserializing completely unstructured data is one thing. But the inability to define, keep, and utilize a structure from server to client to grid and back, is quite another.

Why are we inferring types from strings on grid values?

This silently breaks copy/paste, filter, search, and who knows what else.