1 of 1 people found this helpful
You can look at sp_configureErnst
I’ve honestly not run into this view issue. Can you supply a bit of information?
- what is the originating DB, version, and charset and language is set?
- is the dB (ARSystem) in Unicode?
- what is the new DB, version, and charset and language is set?
- is this dB in Unicode?
- the login properties for the ID which is performing the install, what is its preferred language on each server dB (English is default)?
- Is sp_configure ‘default language’ set to 1 which is German? (This assumes MSSQL)
- what is this server charset and language? You can setup a server to one language and a dB on it to another! So run a (this assumes MSSQL) SELECT @@VERSION get the SQL server info and tell us what it says, then: SELECT Collation_name from sys.databases where name=‘ARSysytem’ [or whatever you’ve called it]
- are you doing an in-place upgrade? If not what are you doing?
- is this form in which the view names are associated with custom or an overlay to ITSM, or other?
- Did you install and configure remedy and set the German language to default before loading the applications? ( doesn’t apply if this is an in place upgrade)
I think once you answer some of this, then Peter Adams can do validate one things to make sure there isn’t a defect With the install. The bottom line is that remedy needs to fully understand what characterset it is reading
we are using ORACLE 12:
AR-Server 7.6.04 Build 00 SP5-S
de_DE.iso88591;WESTERN Oracle Database 12c Enterprise Edition 184.108.40.206.0 64bit Production NLS_NCHAR_CHARACTERSET AL16UTF16 NCHAR Character set NLS_CHARACTERSET WE8ISO8859P15 Character set NLS_LANGUAGE AMERICAN Language IBM
220.127.116.11 p800-007-170629 Linux Linux 4.4.59-92.20-default SUSE Linux Enterprise Server 12
18.104.22.168 Apache Tomcat/7.0.75 JVM
Wenn we migrate to AR Server 9.1 we get:
AR-Server 9.1.06 201811060802 AR-Server
Database 12c Enterprise Edition
22.214.171.124.0 64bit Production NLS_NCHAR_CHARACTERSET AL16UTF16 NCHAR Character set NLS_CHARACTERSET WE8ISO8859P15 Character set NLS_LANGUAGE AMERICAN Language IBM
126.96.36.199 p800-007-170629 Linux Linux 4.4.131-94.29-default SUSE Linux Enterprise Server 12
188.8.131.52 Apache Tomcat/9.0.10 JVM
There are several problems:
1. BMC changed the internal data type for tablenames/viewnames/columnnames from CHAR30 to byte30. So every German umlaut has now 2 bytes, and so columnnames (in user_tab_columns) of exactly 30 character will now be longer than 30 bytes, and so they are cut off.
2. BMC changed the internal mapping rules for view names and column names, for example view name 'SAD:Hello World' and 'SAD:Hello-World' and 'SAD:Hello_World' are now all mapped to the same name: 'SAD_HELLO_WORLD', and to avoid naming conflicts they get a incremental suffix 'SAD_HELLO_WORLD_0001', 'SAD_HELLO_WORLD_0002' and so on.
When the first 26 characters of different field names of one single form differ only in blanks, underlines, minus-sign (anything else?) they get renamed with incremental suffix 0000-9999.
So 'SADIS:User Administration Name' and 'SADIS:User-Administration-Name' will be migrated to 'SADIS_USER_ADMINISTRATION_0001' and .
But not only the characters -, blank and underline are replaced, but a lot of other 'special' characters. But there is no documentation about it. Without documentation you can't avoid such names and even you cant search your database for such names.
The renaming occurs only when you 'touch' the form and modify it. That means your system looks nice after migration to 9.1, but whenever a developer modifies a form with 'strange' name the internal name changes after saving the form. This behaviour is very bad.
We have a lot of C/C++- and Java-Code (and even workflow with DirectSQL) which access the internal tables by name, and now the internal names changed -> big problem.