Hi,
Maybe stupid question but is this normal BPM behaviour?
I have BPM with custom code and comparying ds Company with Session.CompanyID and in some cases this does not work, I noticed that some parts company id are in lower care and sessionID returns it as upper case. I know that db are not key sensitive does this happens becouse C# are key sensitive?
This does not work:
This works:
C# is case sensitive, but the ToUpper shouldn’t typically be necessary because the Part.Company field should have the same casing as the company defined in company maintenance… So you have some data weirdness going on in the Part table…
I would run this by Support to see if they have a datafix to correct the casing on the Part table.
That said, you might as well keep including the ToUpper in your bpms until/unless you figure out the root cause of why some part records are lower case.
Hi,
probably this has happened during migration, because we have chose to migrate with DMT.
I wonder if it is possible to use a BAQ to check how many records a there in lower case, I know this is possible in direct sql, but couldnt do this in BAQ
Not sure if it’s possible in a BAQ. Maybe some clever trick with a calculated field, but nothing obvious comes to mind.
C# case sensitive, wonder if that would work thrue bpm like to build loop and display info msg as grid. I will give it a try
Perhaps. If you’re on prem though can you just run a sql query from ssms?
Normally if you type an ID into a UI form, it does a lookup and replaces what you typed with the case as it’s stored in the DB. I’ve noticed a couple places where it doesn’t. IIRC, the configurator ID associated with a configurator UD method is one example. If you then save the form, it will save a record with the “wrong” case. If you identify another place where this is happening, perhaps write a data directive to correct the case on new rows.
No, we are on cloud
While the == operator is case sensitive, C# as the String.Compare or String.Equal methods which allow you to specify a string comparison that is not case sensitive. You might want to consider one of those.
I have to admit, when I am doing custom code, I often just use == when in theory, I probably ought to be using the string.Compare so it doesn’t look at case. However, Epicor “SHOULD” be entering data in matching case when you’re using key fields of tables. As you mentioned, this could have been caused by a DMT import. If you’re wanting to do a “data fix”, you might have to get a little creative. Perhaps running custom code that moves the upper case company in and performs the update when the “==” is false and the String.Compare is true?
Kevin
