== Why is this an issue?

A primary key uniquely identifies a row in a database table, and should be considered immutable. Primary key values may be used in foreign keys in other tables, as well as in external systems. Changing such a value, even with the best of motivations, is likely to wreak havoc on the system's data integrity and potentially across other systems as well.


*Note* That this rule raises issues only when a database catalog is provided during the SonarQube analysis.


=== Noncompliant code example

[source,cobol]
----
UPDATE USERS
  SET USER_ID = :new-id, USER_NAME = :new-name  *> Noncompliant
  WHERE USER_ID = :input
----


ifdef::env-github,rspecator-view[]

'''
== Implementation Specification
(visible only on this page)

=== Message

"COLUMN_X" is the primary key and should not be updated.


=== Highlighting

primary: column name

secondary: "UPDATE"


'''
== Comments And Links
(visible only on this page)

=== on 11 Jan 2016, 16:35:48 Pierre-Yves Nicolas wrote:
This rule should catch issues on primary keys, but also on partitioning indexes. This is reflected in the message, but not in the current description.

=== on 14 Jan 2016, 16:32:30 Elena Vilchik wrote:
 IMO table name ``++ROW++`` is confusing

=== on 25 Jan 2016, 15:27:48 Pierre-Yves Nicolas wrote:
It seems that checking partitioning columns is more related to performance. Maybe we could add a rule parameter to deactivate that part of the check.

=== on 26 Jan 2016, 14:41:36 Pierre-Yves Nicolas wrote:
In fact, we should think about creating a separate rule to check partitioning columns since the motivation is not the same ("performance" vs "data related reliability").

endif::env-github,rspecator-view[]