# Ignition cleared an index field on a 7 year old table

**URL:** <https://forum.inductiveautomation.com/t/ignition-cleared-an-index-field-on-a-7-year-old-table/7836>\
**Category:** Ignition\
**Created:** [January 14, 2014, 10:32pm UTC](https://forum.inductiveautomation.com/t/ignition-cleared-an-index-field-on-a-7-year-old-table/7836 "2014-01-14T22:32:15Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![SonicClang](https://avatars.discourse-cdn.com/v4/letter/s/eada6e/32.png) [@SonicClang](https://forum.inductiveautomation.com/u/SonicClang)\
**Post date:** [January 14, 2014, 10:32pm UTC](https://forum.inductiveautomation.com/t/ignition-cleared-an-index-field-on-a-7-year-old-table/7836/1 "2014-01-14T22:32:15Z")

</div>

I was doing some testing with data logging in Ignition and it cleared, wiped out, nulled, the index column for a 7 year old table. It’s a table FactorySQL has been logging to. A few minutes with Ignition and there are nothing but nulls now. I’m not a SQL expert. Any suggestions on fixing it??

---

<div class="post-metadata">

**Author:** ![Colby.Clegg](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/colby.clegg/32/3282_2.png) [@Colby.Clegg](https://forum.inductiveautomation.com/u/Colby.Clegg)\
**Post date:** [January 14, 2014, 10:42pm UTC](https://forum.inductiveautomation.com/t/ignition-cleared-an-index-field-on-a-7-year-old-table/7836/2 "2014-01-14T22:42:07Z")

</div>

How would it possibly do that? The column must have somehow been mapped to an item or something… but then… any auto-increment field is usually required to be not-null by the database, so now I really can’t understand how this could happen.

Besides restoring from a backup, I don’t have any good ideas. Is this key something that you can more or less derive? In other words, is it an incrementing number, and the table also has a timestamp or something?

Regards,

---

<div class="post-metadata">

**Author:** ![adamaustin](https://avatars.discourse-cdn.com/v4/letter/a/5f8ce5/32.png) [@adamaustin](https://forum.inductiveautomation.com/u/adamaustin)\
**Post date:** [January 15, 2014, 3:44pm UTC](https://forum.inductiveautomation.com/t/ignition-cleared-an-index-field-on-a-7-year-old-table/7836/3 "2014-01-15T15:44:26Z")

</div>

If there are no other FOREIGN KEYS pointing to this table, you could add the column back in and let it auto-populate the values for you:

MySQL:

```auto
ALTER TABLE *YOUR_TABLE* DROP COLUMN id

ALTER TABLE *YOUR_TABLE*
ADD id INT NOT NULL AUTO_INCREMENT, ADD PRIMARY KEY(id)
```

MS SQL:

```auto
ALTER TABLE *YOUR_TABLE* DROP COLUMN id

ALTER TABLE *YOUR_TABLE*
ADD id INT NOT NULL IDENTITY(1,1)
```

---

<div class="post-metadata">

**Author:** ![malleblas](https://avatars.discourse-cdn.com/v4/letter/m/ea666f/32.png) [@malleblas](https://forum.inductiveautomation.com/u/malleblas)\
**Post date:** [February 5, 2014, 3:38am UTC](https://forum.inductiveautomation.com/t/ignition-cleared-an-index-field-on-a-7-year-old-table/7836/4 "2014-02-05T03:38:05Z")

</div>

As a protection measure, once I have my database all set up, I limit the privileges that the database user Ignition can have over the database to prevent these types of things.  
I allow only the bare minimum privileges for each table.
