Skip to main content
Solved

Case sensitivity in custom table inserts after upgrade to 6675.1

  • 27 June 2024
  • 8 replies
  • 82 views

After upgrading to TimeXtender 6675.1, we are experiencing some errors when executing custom table inserts. The error message is ‘The given ColumnMapping does not match up with any column in the source or destination’.

As it turns out, we have a few CTI's where the target column name was spelled with a capital letter when in fact the column name was with a lowercase or vice versa. This was never a problem but we had to correct this in the newest 6675 version. Has there been a change in where the CTI's target columns are now case sensitive?

8 replies

Thomas Lind
Rank
Userlevel 6
Badge +5

Hi @wouter.goslinga 

I will see if I can get an answer of this.

R
Rank
Userlevel 3

Are you using a new/different database that has a case sensitive collation?

wouter.goslinga
Rank
Userlevel 2
Badge +2

No, only change is upgrade TX from 6645 to 6675

Thomas Lind
Rank
Userlevel 6
Badge +5

Hi @wouter.goslinga 

You can make it work by matching the cases, right?

Besides that, it seems to be a consequence of changing the SQLClient. 

wouter.goslinga
Rank
Userlevel 2
Badge +2

@Thomas Lind correct, if the cases match it works again. We did indeed update the TX SQL Client to the latest version, so that could very well be the case.

Maybe, if this is by design / not a bug, this should be listed as a warning in the release notes because it can possibly break execution without notice in advance.

rory.smith
Rank
Userlevel 6
Badge +7

Hi,

the collation of your database (or table or column for data) should decide case sensitivity. If your collation has CS then that should always result in those kind of issues, CI should not. Snowflake has this for instance.

TimeXtender should not be adding case sensitivity for systems that are not without explicitly notifying users of such a change, in my opinion. Of course, if you decide to move to something like Snowflake or a CS collation on your SQL infrastructure, you would need to refactor all your custom SQL.

Thomas Lind
Rank
Userlevel 6
Badge +5

@Thomas Lind correct, if the cases match it works again. We did indeed update the TX SQL Client to the latest version, so that could very well be the case.

Maybe, if this is by design / not a bug, this should be listed as a warning in the release notes because it can possibly break execution without notice in advance.

Hi @wouter.goslinga 

It is a bug, I just wanted to know if you could continue.

It will be fixed in a future hotfix release.

Christian Hauggaard
Rank
Userlevel 6
Badge +5

@wouter.goslinga a fix for this has now been released in

 

Reply


Terms and ConditionsCookie settings