fix issue in upgrade script that caused issues with unicode characters when upgrading

Re-verified the changed code exists and that it does not impact installation in case insensitive SQL databases.
Platform 7.3.4 build 45

Verified the changed code exists
Does not impact installation in case insensitive SQL databases.

jan, of course there are a couple of names, where there might be multiple alternatives, but it is necessary to use same spelling on all tables, views and sprocs, where the column (or a local variable) is used, otherwise it becomes a nightmare.

Hello Sebastian,
I agree with your "camelcase" opinion. That was the first thought I had at the beginning of solving this problem. Theoretically. Then I looked at the code, and for the sake of my health I decided to choose the easier way. The code of the application is very complex, and it is visible that many developers are working on it. Problem also is that not everyone understands the same thing under "camelcase". For example, someone writes "codeSubDirectory", and someone else writes "codeSubdirectory". I have seen this in the code. Which one is correct? In general I agree with enforcing a default notation style (such as "camelcase"). But how?

Jan,
DNN is storing all language specific texts as Unicode, which means there is usually no need to use a case sensitive collation on the database, except for comparisons (which are usually not applied to text, only to keys)