Cannot create new threshold template

[jdcoats]

2020/04/16 15:55:11 - CMDPHP SQL Backtrace: (/plugins/thold/thold_templates.php[46]:template_add(), /plugins/thold/thold_templates.php[555]:sql_save())
--
2020/04/16 15:55:11 - DBCALL ERROR: SQL Save on table 'thold_template': Column 'data_template_hash' does not exist, unable to save!

[jdcoats]

I tracked down the following in database.php

 if (cacti_version_compare($oldv, '1.2.3', '<')) {
                db_add_column('thold_data', array(
                        'name'     => 'data_template_hash',

So I changed the version in INFO to 1.2.2 and disable/enable plugin then changed version back to 1.4 disable/enable and problem solved.

[TheWitness]

Wow, was your upgrade half pregnant? Do you know how you got in that state?

[jdcoats]

probably by following your'e commits on a regular basis and my version got upgraded before you wrote the code to create the column. :0

[TheWitness]

Bless you @jdcoats. Keeping this dog running get's harder each year.

[chris-y]

@jdcoats I'm encountering this issue myself today (haven't needed any new templates for ages). I tried modifying the plugin version in thold/INFO, disabling/re-enabling, changing back etc, but that doesn't work here.

[chris-y]

Hmm, ended up adding it manually along with suggested_name and show_units. Odd.

[Scarehcrow]

I'm having the same issue after upgrading thold from 1.0.4 to 1.5.2

I've enabled and disabled the plugin a few times without avail. @chris-y can you tell me which sql command you used to create those columns? I've looked around for an .sql file which would describe the layout of the table but havn't found it.

[chris-y]

This comes from my SQL history so I may have missed something or copied the wrong commands, use at your own risk. I'm not a SQL expert, I had to Google this originally!

use cacti;
ALTER TABLE thold_template ADD data_template_hash varchar(32);
ALTER TABLE thold_template ADD suggested_name varchar(32);
ALTER TABLE thold_template ADD show_units char(3);

DESCRIBE thold_template; will show you the current table layout. Mine includes:

+-----------------------------+------------------+------+-----+---------+----------------+
| Field                       | Type             | Null | Key | Default | Extra          |
+-----------------------------+------------------+------+-----+---------+----------------+
| data_template_hash          | varchar(32)      | YES  |     | NULL    |                |
| suggested_name              | varchar(32)      | YES  |     | NULL    |                |
| show_units                  | char(3)          | YES  |     | NULL    |                |
+-----------------------------+------------------+------+-----+---------+----------------+

[netniV]

So, I'm not sure why you guys experienced this issue. I just upgraded and those all went through fine for me. One thing it may be due to is zero dates? MySQL has gotten stricter about not using zero dates, but the definitions may have had them already. If your instance doesn't allow zero dates you will get errors trying to add or remove columns such as this.

[chris-y]

I did get extra errors just now trying to modify a threshold (not template). Had to add show_units but it wouldn't let me because of the default date. Ended up having to run

ALTER TABLE thold_data
   CHANGE `lasttime` `lasttime` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
   CHANGE `lastchanged` `lastchanged` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP;

Before it would let me add the missing show_units:

ALTER TABLE thold_data ADD show_units char(3);

I'm not sure if those timestamp default changes are correct.

[bmfmancini]

Which Version are you using and from which branch ? this sounds like you are using the dev branch

On Mon, Aug 23, 2021 at 6:51 AM Chris Young @.***> wrote:

I did get extra errors just now trying to modify a threshold (not template). Had to add show_units but it wouldn't let me because of the default date. Ended up having to run

ALTER TABLE thold_data CHANGE lasttime lasttime TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, CHANGE lastchanged lastchanged TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP;

Before it would let me add the missing show_units:

ALTER TABLE thold_data ADD show_units char(3);

I'm not sure if those timestamp default changes are correct.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Cacti/plugin_thold/issues/421#issuecomment-903657310, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADGEXTCK6AUNOOMP33LCDC3T6IR2NANCNFSM4MKC5HSQ .

-- Thank you

Sean Mancini,(Six Sigma LBBIT®, ITIL,CEA-IT®,SCRUM SMPC®) Owner/Principal Engineer www.seanmancini.com

“Companies spend millions of dollars on firewalls, encryption, and secure access devices, and it’s money wasted because none of these measures address the weakest link in the security chain.”

– Kevin Mitnick

[chris-y]

This is from some breakage caused by using a dev version a while back.

[netniV]

This is due to zero date defaults which I've discussed with @TheWitness before, but currently we haven't come to an agreement on.

[TheWitness]

So long as you are following our recommendations relative to database setting, there should not be an issue.

[netniV]

I am thinking we need to enforce some mysql defaults, rather than let the admin move past them. Zero dates being allowed is definitely one of them because currently that will break a lot of things for us.