Improve database logging when a crashed table is encountered

[YongBoLiu]

Describe the bug
A clear and concise description of what the bug is.
An error of division by zero shows up, but real cause is the poller_item table crashed, as below. And the no errors about the SQL reported in the Clog.

2019/11/05 14:25:08 - CMDPHP PHP ERROR WARNING Backtrace: (/poller_boost.php[137]:output_rrd_data(), /poller_boost.php[298]:CactiErrorHandler())

2019/11/05 14:25:08 - ERROR PHP WARNING: Division by zero in file: /opt/cacti/poller_boost.php on line: 298

MariaDB [cacti]> SELECT po.output, po.time, UNIX_TIMESTAMP(po.time) as unix_time, po.local_data_id, dl.data_template_id, pi.rrd_path, pi.rrd_name, pi.rrd_num FROM poller_output AS po INNER JOIN poller_item AS pi ON po.local_data_id=pi.local_data_id AND po.rrd_name=pi.rrd_name INNER JOIN data_local AS dl ON dl.id=po.local_data_id ORDER BY po.local_data_id;
ERROR 144 (HY000): Table './cacti/poller_item' is marked as crashed and last (automatic?) repair failed

To Reproduce
Steps to reproduce the behavior:

1. Make a table crash, such as poller_item
2. Run a SQL about the table.
3. Check the Clog

Expected behavior
A clear and concise description of what you expected to happen.
The DB error should be reported correctly.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: [e.g. iOS]
• Browser [e.g. chrome, safari]
• Version [e.g. 22]
  Linux 7
  Firefox 60

Smartphone (please complete the following information):

• Device: [e.g. iPhone6]
• OS: [e.g. iOS8.1]
• Browser [e.g. stock browser, safari]
• Version [e.g. 22]
  cacti 1.2.7

Additional context
Add any other context about the problem here.
The errorcode compare in the db_execute_prepared() is NOT right. Because a string always equal with 0. As below,

[root@yboliu_rhel720 /]# php -r "if('HY000' > 0) echo 'Bigger '; if('HY000' == 0) echo 'equal ';"
equal [root@yboliu_rhel720 /]# 

[YongBoLiu]

How about fix it as below, I am not very sure we should take the '01000' as succeed.

diff -u -N rtm/cacti/lib/database.php rtm/cacti/lib/database.php
--- rtm/cacti/lib/database.php	2019-08-01 22:33:00.000000000 +0800
+++ rtm/cacti/lib/database.php	2019-11-05 16:16:42.000000970 +0800
@@ -252,12 +252,12 @@
 
 		if ($code == 0) {
 			$code = $query->errorCode();
-			if ($code > 0) {
+			if ($code != '00000' && $code != '01000') {
 				$errorinfo = $query->errorInfo();
 				$en = $errorinfo[1];
 			}  else {
 				$code = $db_conn->errorCode();
-				if ($code > 0) {
+				if ($code != '00000' && $code != '01000') {
 					$errorinfo = $db_conn->errorInfo();
 					$en = $errorinfo[1];
 				}
Ref: https://www.php.net/manual/en/pdo.errorcode.php

[YongBoLiu]

[root@yboliu_rhel720 /]# php -v
PHP 5.4.16 (cli) (built: Jan 23 2018 07:26:54)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies

[netniV]

Because 01000 means data truncated which can happen in string description fields especially when take from snmp directly. It is basically a warning not an error.

[YongBoLiu]

@netniV , thanks. So, we need to fix the db_execute_prepared(). Because it can't report error messages correctly when there are letters in the errorcode, such as HY000.

[netniV]

Yeah, that seems reasonable to me.

[netniV]

Actually, this is a fundamental chance that I think should really be done in the 1.3.0 release. We could suddenly be swamped with error messages that were not previously presented and these may not come out during a standard patch testing cycle but only with end users.

[cigamit]

Well, that is very interesting. I'll correct the divide by zero, and then conduct a little more research on the crashed table in the few hours I have left.