Version 2 by Brad Shaw
on Jun 09, 2016 20:53.

compared with
Current by Brad Shaw
on Feb 14, 2017 01:15.

This line was removed.
This word was removed. This word was added.
This line was added.

Changes (5)

View Page History
It is recommended that all ViewX clients be upgraded to ClearSCADA 2015 R1.1 following successful upgrade of the server(s).

{info}Supported client versions include ClearSCADA 2013 R1, ClearSCADA 2013 R2, and ClearSCADA 2014 R1, and ClearSCADA 2015 R1 (and corresponding Service Packs for each version).
ViewX clients prior to ClearSCADA 2013 R1 will not be able to connect to a ClearSCADA 2015 R1.1 server.{info}

h1. Upgrading from ClearSCADA 2014 R1.x

{*}Please *Please be aware of all the issues covered in the previous sections in addition to the following.*
* The ClearSCADA Sample Database now appears as two “Configuration Samples” options within a custom ClearSCADA installation to allow users the choice of whether or not this is installed. At completion of the ClearSCADA installation, there is no longer a Demonstration Modules installer to launch the Database and install the Configuration Samples. Instead, when the Configuration Samples are selected for installation (included within a “Full” installation) the Sample Database will automatically be loaded when the ClearSCADA server is started if an existing database is not found.

* Prior to upgrading the user needs to stop the ClearSCADA mobile companion service using the ClearSCADA Service Manager tool.

* Creation of a ClearSCADA Super User account is now mandatory during installation in order to provide administration access to configure new Example User Accounts. It is strongly recommended that this is disabled via the System Configuration utility once a replacement Administrator user account has been created within the database.

* The built-in Super User account, if enabled, is only valid on the local ClearSCADA server machine, and will be denied access to ClearSCADA if logon is attempted from a remote client machine.
* A new database table, called DBDictionary, has been created to store the translation strings for each dictionary language as required by the user. Each entry within this table specifies the Dictionary Name (or Language), a Search String, a Replacement String, and an optional Comment. When configured, users who have their Locale set to match one of the Dictionary Languages would see the Replacement String used in place of a Search String if it were to appear on a mimic.
** Enabling the dictionary functionality as described above will disable translation using any existing Dictionary Files. In this case, migration of these existing files to the new dictionary table is necessary to provide continued translation.
** Translation of strings using the string dictionary only works for whole strings. Strings on mimics cannot be built from multiple translated strings. A new “translate()” function has been created for use within server expressions, client expressions, scripting and SQL syntax to allow multiple separate strings to be translated and concatenated together. An example mimic text animation could include:
{noformat}Translate(‘@This section of string is translated’) + ‘ but this section is not.’{noformat}