Automic Workload Automation

  • Private Community

  • 1.  Turkish characters are not displayed correctly in e-mail notifications

    Posted Jan 22, 2018 08:01 AM
    This question came up in a recent support inquiry :

    How can one enable Turkish characters in e-mails sent via the Automation Engine ?


    Answer :

    This is related to the character set of the database: the AE can not properly store / use a character which is not part of its database character set. Please note that only the character sets listed below are supported with the AE database.


    DB2 :

    ASCII code table (code set 819 for ISO8859-1, code set 923 for ISO8859-15)


    Oracle  :



    MS SQL :

    • "Latin1_General_CI_AS"
    • "SQL_Latin1_General_CP1_CI_AS" (CP 1252)


    Source : https://docs.automic.com/documentation/webhelp/english/AWA/12.1/DOCU/12.1/AWA%20Guides/help.htm#Installation_Common/PreparationSteps/Preparingforthemanualinstallation.htm?Highlight=codeset


    Best regards,
    Antoine


  • 2.  Turkish characters are not displayed correctly in e-mail notifications

    Posted Jan 22, 2018 08:07 AM
    It might be a workaround using powershell or mailx OS function to send mails containing the correct characters..

    https://community.automic.com/discussion/comment/32343#Comment_32343



  • 3.  Turkish characters are not displayed correctly in e-mail notifications

    Posted Jan 23, 2018 06:16 AM
    out database parameters section below. this is supported right ? 


    NLS_RDBMS_VERSION                     12.1.0.2.0
    NLS_NCHAR_CONV_EXCP               FALSE
    NLS_LENGTH_SEMANTICS              BYTE
    NLS_COMP                            BINARY
    NLS_DUAL_CURRENCY                     $
    NLS_TIMESTAMP_TZ_FORMAT         DD-MON-RR HH.MI.SSXFF AM TZR
    NLS_TIME_TZ_FORMAT              HH.MI.SSXFF AM TZR
    NLS_TIMESTAMP_FORMAT                 DD-MON-RR HH.MI.SSXFF AM
    NLS_TIME_FORMAT                     HH.MI.SSXFF AM
    NLS_SORT                              BINARY
    NLS_DATE_LANGUAGE               AMERICAN
    NLS_DATE_FORMAT                         DD-MON-RR
    NLS_CALENDAR                         GREGORIAN
    NLS_NUMERIC_CHARACTERS             .,
    NLS_NCHAR_CHARACTERSET              AL16UTF16
    NLS_CHARACTERSET                    WE8ISO8859P9
    NLS_ISO_CURRENCY                    AMERICA
    NLS_CURRENCY                         $
    NLS_TERRITORY                         AMERICA
    NLS_LANGUAGE                       AMERICAN



  • 4.  Turkish characters are not displayed correctly in e-mail notifications

    Posted Jan 23, 2018 06:37 AM
    Hi,

    [EDIT]

    This character set : NLS_CHARACTERSET                    WE8ISO8859P9  is not supported.

    Best regards,
    Antoine



  • 5.  Turkish characters are not displayed correctly in e-mail notifications

    Posted Jan 23, 2018 01:30 PM
    Attention: NLS_CHARACTERSET          WE8ISO8859P9 is used here. That doesn't match the character sets listed above.


  • 6.  Turkish characters are not displayed correctly in e-mail notifications

    Posted Jan 24, 2018 04:32 AM
    Thanks Alexander_Trenker_120 I missed that! Just edited my answer above.

    Olgun_Onur_Ozmen : Sorry for my previous answer, but the character set you are currently using is not supported.

    WE8ISO8859P9 --> ISO-8859-9 turkish support.
    We thought that this character set supported the Turkish language. If we have the option to change the database character set to WE8ISO8859P15 , does this affect Automic ?
    Changing the character set of a database is, very complicated once the db has been used for some time. I'm not a DB expert but it would be surprising if the data already contained in the DB was not affected.
    Besides, even if you did migrate, it would not mean that Turkish characters would be supported.

    What you could do, however, is ask for the ability to use Turkish characters in a later version of the software.
    Please submit an enhancement request at ideas.automic.com for this purpose.

    Best regards,
    Antoine


  • 7.  Turkish characters are not displayed correctly in e-mail notifications

    Posted Jan 24, 2018 07:44 AM
    Tough news in foreign markets. Ah well, there's a solution for everything: sed 's/ 温子, 篤子, 敦子/John/g'. Congrats on the new name :)

    On a more serious note: If an idea is filed, it should be an idea for AE to support UTF-8, instead of ideas for individual ISO code pages. UTF-8 is the agreed upon future and covers (near as makes no difference) everything the world needs: Turkish, Indian, Thai, Japanese, and even the strangely coloured ice cream emoji.

    I'm surprised there is no idea.automic.com entry for that yet, I was quite certain there was one. On the other hand, quite frankly, UTF-8 support has been promised as something that's on Automic's agenda on so many occasions, it should already long be in the design pipeline.


  • 8.  Turkish characters are not displayed correctly in e-mail notifications

    Posted Jan 24, 2018 07:51 AM

    I've just entered the "idea" for full UTF-8 support on ideas.automic.com Once (or if) it's approved for voting, it can be voted on here.



  • 9.  Re: Turkish characters are not displayed correctly in e-mail notifications

    Posted Apr 19, 2018 07:21 AM

                   I spoke extensively with DBA's here. He added that WE8ISO8859P9 has already supported full Turkish on database. For the experiment, we found the database table with the turkish characters we kept in the process tab of our mail objects. Automic keep this information in the hugeclobs on the OT table with the idnr over the OH table, and we have seen that it keeps the turkish characters properly. In this case, we can make a comment. These characters are kept properly in the database, but I think the engine is converting it in the process of sending.
                 The DBA's proposal initially set up a session-based character set, but when he saw that he was being held properly in the OT table, he said he would have to set it up from the top.

                   Any comment on this case ?  Can we solve with set alter the session-based somewhere on the database? or workaround ?