I have a data directive in place that is supposed to go out to a UD table and grab relevant data from it. Issue is I just realized that the UD table is sorting by the keys entered and this means that within the table my data is out of order. EX: 1,11,111,2,22,222.
I need a way of populating the UD table so that everything is in order. EX: 1,2,11,22,111,222.
The “keyx” fields in the UD tables are text fields… so they ARE in alphabetical order. If you want them to be in numerical order, you’ll need to rethink how you might want to use the tables.’
Can you also use the “Numberx” fields, and sort them that way?
I could say “dont do that” but that is not very productive…
Whenever you have an indexed value that is stored in a string, this will be a challenge. Options include:
always zero fill… ie… 001, 002, 011, 022, 111, 222
make your numbers a bigger number (preferred over the zero fill) ie… 100001, 100002, 100011, etc
OR ALSO, put the NUMBER into a numeric field, and then sort the results by that field. So the data would be stored twice, but the numeric value would resolve the issue after returning the data.
I’m not sure how I would sort the table numerically within C# code. I was originally trying to just use the Number X fields as mentioned but UD tables require their keyx fields to have unique entries in order to populate them.
I agree, but I have little choice unless there is somewhere else to store custom data within Epicor. I like the idea of step 2. I’m going to give it a shot and let you know where I end up. Thanks for the quick responce!
Glad it helped… Just to fill out the solution, You can end up with similar problems with DATES. If you put a date into a string valued KEY, you really need to sort it in Year/Month/Date sequence so that it sorts correctly. The old school method was to make sure that today’s date (May 6, 2021) would be stored as in various flavors such as one of the following to get consistent sorting:
20210506
2021-05-06
2021/05/06
Below works great until the end of the century, when you run into similar problems as Y2K caused. But we dont have to worry about that for another 79 years. (Thats about what was said in the 1960s and 70s).
210506
21-05-06
21/05/06