Applies To:
  • CitectSCADA 6.x, 7.x
Summary:
How do the User record changes in Display clients and Server work?

Solution:

There are two types of changes you can make one is Design Time changes (Adding or Changing a record in Project Editor) and the other is Runtime changes. Also the changes made works in a different way for different project setup (Having a local copy of the project in client or Using "Add Project Link" to link project directly from the Server machine or FileServer)I have explained all scenarios below and how it affects the Redundant Server and Client.

DESIGN TIME CHANGES:

Scenario 1: Design Time Changes with Local copy of the Project in client and Redundant Server and NOT using [CTEDIT]Copy parameter.

When you add or edit a User (in project editor) in the Primary Server and compile its not automatically reflected in runtime (even if you refresh pages) in Primary, Secondary and Client. After a compile and restart (all three Primary, Secondary and client) you can see the changes only in Primary and never gets propagated to the Secondary and client.

Scenario 2: Design Time Changes with Local copy of the Project in client and Redundant Server and using [CTEDIT]Copy parameter in both Secondary and Client.

When you add or edit a User (in project editor) in the Primary Server and compile its not automatically reflected in runtime (even if you refresh pages) in Primary, Secondary and Client. After a compile and restart you can see the changes in Primary and machines which are using the Copy parameter.

As you can see that if you use the [CTEDIT]Copy parameter a restart will propagate the changes to that client.

Scenario 3: Design Time Changes with Remote copy of the Project in client (Using Add Project Link from the Primary Server User Folder).

NOTE: This does not apply for Redundant server as usually they have a local copy of the project.

When you add or edit a User (in project editor) in the Primary Server and compile its not automatically reflected in runtime (even if you refresh pages) in Primary, Secondary and Client. After a compile and restart you can see the changes in Primary and Client running on the project in remote file server.

There are also other options through which you can copy changes like using FileCopy() command to copy User files (Users.dbf and _Users.rdb) from the server machine to the client machine but this still requires a restart of the client runtime. In general any Design time changes to User records cannot be reflected over to the clients and servers without restarting them.

RUNTIME CHANGES:

Please note you cannot make Runtime changes V7.x without a Alarm Server so you need to define a Alarm Server to make Runtime changes to User records. Refer to Q4870.

Scenario 4: Runtime Changes with Local copy of the Project in client and Redundant Server and NOT using [CTEDIT]Copy parameter.

When you add or edit a User (in runtime) in the Primary Server and refresh the pages its reflected in Primary but not in Secondary and Client. After a compile and restart of all the machines you can see the changes only in Primary and never gets propagated to the Secondary and client.

Scenario 5: Runtime Changes with Local copy of the Project in client and Redundant Server and using [CTEDIT]Copy parameter in both Secondary and Client.

When you add or edit a User (in runtime) in the Primary Server and refresh the pages (on all three machines) it gets reflected in all three machines Primary, Secondary and Client.

Scenario 6: Runtime Changes with Remote copy of the Project in client (Using Add Project Link from the Primary Server User Folder).

NOTE: This does not apply for Redundant server as usually they have a local copy of the project.

When you add or edit a User (in runtime) in the Primary Server and refresh the pages (on all machines) it gets reflected in both Server and client machines. 

Please note all these tests were carried in Single Process Mode. If you are running Multi-process then the client running on the Server machine will be considered as the remote client and the rules of a Remote client will apply.
Keywords:
 User records, Password change

Attachments