ABL To C sharp


Hello All

On converting the ABL to C Sharp BPM Code Conversion, the UD Fields Shortchar01, 02…
not available in ttTable getting an error and when we use Db.Table the Fields are available without any issues.

Have anybody faced this issue

Below is an example

From DB this worked
var vShipDtl = (from xRow in Db.ShipDtl where xRow.ShortChar02 == “” select xRow)

From ttTable this is not working
var vttShipDtl in(from xRow in ttShipDtl where((xRow.RowMod == “A” || xRow.RowMod == “U”) &&
(xRow.ShortChar02 == “” || xRow.shortchar04 == “”


Take a look at the Programmer Guide in Epic web it covers all this in detail regarding the ABL to C# conversion and how to do it.


Try using the format shown in the “C# Programming Guide (conversion from ABL)”

try this:

var vttShipDtl = ttShipDtl.Where(x => "AU".Contains(x.RowMod) && x["ShortChar02"] == "" || x["ShortChar04"] == "");
1 Like

Took me a second or two to figure out what that was. Is that faster than:
(x.RowMod == "A" || x.RowMod == "U")


@ckrusen Science says…


@ckrusen .Contains is slower than a standard comparison but you would be splitting hairs. When it comes to “.Contains”, “.Equals”, and “==” cultural variants and accuracy of the comparison come into play. Certainly not the bottleneck in an application I would ever worry about. Get out the ruler!



Your science is flawed! Use VStudio performance metrics you charletan!

I’ve used the UOM of “C HAIRS”, but have never seen a ruler marked in them.

Do they make micrometers that measure in “RED C HAIRS” ??

They make an actual tape measure. You can buy it.

Hey I can’t “embed” that here, so shut it, evidence based science is science, you can click run 100X above and see the results.

I provided the experiment not the result, notice is said “Science Says”… (I didn’t give an answer) Like a good scientist, I provide the data and let you (or Fox / CNN) extrapolate whatever they want out of it :joy: and bend it to fit your narrative!

1 Like

For example here is a view

Contains is slower (as demonstrated above) because it needs to loop through the “AU” and RowMod strings one character at a time and compare each character the other characters on the second string thus looping a maximum total of N^M times.

Where N and M are the lengths of each string. Causing the operational efficiency to be in the notation of Big O(N)

While the OR statement compares at most twice, and generally once (because of short circuit) with a Big O (1) constant time.


PS: See Big O Notation for the layman :yum:

1 Like

And I prefer the readability of (x.RowMod == "A" || x.RowMod == "U")

It tells you exactly what you’re looking for.

1 Like

Epicor says dont use RowMod but (x.Added() || x.Updated()) or !x.Unchanged()

1 Like

Do they say why?

I think future thinking, they could always change the character I assume. Unlikely, but could.

I guess they also make it case-insensitive in case if some form still sends it in lowercase and check for null.

1 Like

Makes sense …

But is


faster than

(row.RowMod == "U" || row.RowMod == "u")


BAHAHA!.. (Updating the science) stand by

@ckrusen New Science says…

Whatever you do dont use .ToUpper() :slight_smile:

1 Like