# Primary key on alarm\_event\_data **URL:** \ **Category:** Ignition\ **Created:** [January 26, 2022, 6:52pm UTC](https://forum.inductiveautomation.com/t/primary-key-on-alarm-event-data/55414 "2022-01-26T18:52:57Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![vrautomation](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/vrautomation/32/11155_2.png) [@vrautomation](https://forum.inductiveautomation.com/u/vrautomation)\ **Post date:** [January 26, 2022, 6:52pm UTC](https://forum.inductiveautomation.com/t/primary-key-on-alarm-event-data/55414/1 "2022-01-26T18:52:57Z")
Hello community! Using SQL Server, We are setting up data replication of alarm\_event\_data. It seems to be impossible because this table do not have a primary key. Is there a problem if I add a pk\_id autoincrement column as a primary key? ---
**Author:** ![dkhayes117](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/dkhayes117/32/68344_2.png) [@dkhayes117](https://forum.inductiveautomation.com/u/dkhayes117)\ **Post date:** [January 26, 2022, 7:57pm UTC](https://forum.inductiveautomation.com/t/primary-key-on-alarm-event-data/55414/2 "2022-01-26T19:57:01Z")
That’s weird. I have some alarm\_event\_data tables, and they all have a primary key field named `id` ---
**Author:** ![vrautomation](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/vrautomation/32/11155_2.png) [@vrautomation](https://forum.inductiveautomation.com/u/vrautomation)\ **Post date:** [January 26, 2022, 8:00pm UTC](https://forum.inductiveautomation.com/t/primary-key-on-alarm-event-data/55414/3 "2022-01-26T20:00:12Z")
The column name id is not a primary key. It is a link with the table alarm\_event. A primary key must be different for all rows in a table. This is not the case here: ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/b/a/baf5bffc7a2ad6c48a128dcd9d165631b0e7f855.png) ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [January 26, 2022, 8:21pm UTC](https://forum.inductiveautomation.com/t/primary-key-on-alarm-event-data/55414/4 "2022-01-26T20:21:51Z")
Use a composite primary key of id+propname. Unless you are using old MySQL, which can’t do that. ---
**Author:** ![knicholas](https://avatars.discourse-cdn.com/v4/letter/k/71e660/32.png) [@knicholas](https://forum.inductiveautomation.com/u/knicholas)\ **Post date:** [April 4, 2022, 12:37pm UTC](https://forum.inductiveautomation.com/t/primary-key-on-alarm-event-data/55414/6 "2022-04-04T12:37:01Z")
May I ask which SQL platform you are using and if you were able to make the id column to be Composite Primary Keys? I am using MySQL 8.0.26 and having this same issue. ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [April 4, 2022, 1:03pm UTC](https://forum.inductiveautomation.com/t/primary-key-on-alarm-event-data/55414/7 "2022-04-04T13:03:06Z")
MySQL 8.0 documentation suggests you should be able to: [MySQL :: MySQL 8.0 Reference Manual :: 8.3.6 Multiple-Column Indexes](https://dev.mysql.com/doc/refman/8.0/en/multiple-column-indexes.html) ---
**Author:** ![dries\_Smeuninx](https://avatars.discourse-cdn.com/v4/letter/d/6bbea6/32.png) [@dries\_Smeuninx](https://forum.inductiveautomation.com/u/dries_Smeuninx)\ **Post date:** [April 8, 2024, 11:00am UTC](https://forum.inductiveautomation.com/t/primary-key-on-alarm-event-data/55414/8 "2024-04-08T11:00:22Z")
Hi Phil, I've a similar issue with the Ignition Historian tables, no primary key for replication available in a MSSQL Server 2019: - sqlth\_partitions - sqlth\_sce How do I've to configure your proposed solution? Add a KP ID column or a composite primary key column in those tables? Will the extra PK in both tables influence the normal functionality of the Ignition Historian? Thanks for you reply, Dries ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [April 8, 2024, 12:20pm UTC](https://forum.inductiveautomation.com/t/primary-key-on-alarm-event-data/55414/9 "2024-04-08T12:20:22Z")
You can't have two primary keys. Replace the original primary key with a composite. Perhaps recreate the original as a non-clustered index. As for operations, MSSQL's memory consumption for caching the primary key will increase. ---
**Author:** ![dries\_Smeuninx](https://avatars.discourse-cdn.com/v4/letter/d/6bbea6/32.png) [@dries\_Smeuninx](https://forum.inductiveautomation.com/u/dries_Smeuninx)\ **Post date:** [April 8, 2024, 2:04pm UTC](https://forum.inductiveautomation.com/t/primary-key-on-alarm-event-data/55414/10 "2024-04-08T14:04:09Z")
Thanks Phil, I could solve this by adding an IDENTITY PRIMARY KEY "id" in the two tables. This way standard MSSQL replication can be used, because now all Ignition Historian tables have a primary key. Kind regards, Dries ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [April 8, 2024, 2:11pm UTC](https://forum.inductiveautomation.com/t/primary-key-on-alarm-event-data/55414/11 "2024-04-08T14:11:51Z")
Sure. Just keep an index on t\_stamp, at the very least. (Probably also on tag\_id.)