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 == “”
@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!
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 and bend it to fit your narrative!
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.
and bend it to fit your narrative!
