Please Share your Product Ideas with us!

All ideas are welcome. Just because the Idea doesn't make it into the product immediately does not make it a bad idea.

Value Mapping: LIST_TARGET_VALUE table should have case-sensitivity for LOAD & TARGET by design/default

I needed to add T002 to value mapping today, and there's enough variants maintained at the client to need case-sensitivity.


Of course, once I turn it on for the fields "LOAD_VALUE" and "TARGET_VALUE", I then have to go back into all my existing value mapping and add "collate SQL_Latin1_General_CS_AS " to all my existing value mapping pulls that didn't previously need it (OK, for these I can add CI_AS technically, but thats' not the point). Otherwise, I can't refresh the table.


Can we make it so that these fields are case-sensitive at point of build of table (XT_VALUEMAP too), and the "auto logic" that tries to do "load_value" and "target_value" uses collation logic by default?


Mapping the values back to the working table already does the CI_AS collation as we assume it's not going to be case-sensitive in the working table, so it's relativey striaghtforward, I think!?

  • Guest
  • May 25 2023
  • Attach files
  • Guest commented
    July 06, 2023 05:17

    Agreed - 100% CS everywhere will be a PITA until we all get used to it (a couple of weeks), but it's the logical solution. Attention to detail is what makes a project run smoothly, so this shouldn't be an issue if declared at the point project inception.

  • Admin
    John Munkberg commented
    July 06, 2023 03:15

    Oracle and HANA are truly case sensitive. We updated the naming convention to be UPPERCASE to accomodate those systems. I think we are getting closer to just say all the SQL Server working databases (WRK, SRC, TGT, MIGRATE, etc) should be created as Case Sensitve by default. That solves the entire problem.


    Thoughts?