Need to recreate log table in Xibo Database

Get Help
1

Running Xibo 1.4.1. I inadvertently dropped the log table instead of emptying. I do not have a recent backup from before this was removed. What are the exact MySQL commands needed to re-setup this log table?

C:\inetput\wwwroot\xibo\err_log.xml is growing out of control with the following error messages:

IN

The query [INSERT INTO log (logdate, type, page, function, message, RequestUri, RemoteAddr, UserAgent, UserID, displayID, scheduleID, layoutID, mediaID) VALUES (‘2016-10-24 08:16:21’,‘audit’, ‘DisplayGroup’, ‘Touch’, ‘IN’, ‘/xibo/xmds.php’, ‘10.0.4.206’, ‘Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol 2.0.50727.5485)’, 0, 0, 0, 0, 0)] failed to executeTable ‘xibo.log’ doesn’t exist

OUT

The query [INSERT INTO log (logdate, type, page, function, message, RequestUri, RemoteAddr, UserAgent, UserID, displayID, scheduleID, layoutID, mediaID) VALUES (‘2016-10-24 08:16:21’,‘audit’, ‘DisplayGroup’, ‘Touch’, ‘OUT’, ‘/xibo/xmds.php’, ‘10.0.4.206’, ‘Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol 2.0.50727.5485)’, 0, 0, 0, 0, 0)] failed to executeTable ‘xibo.log’ doesn’t exist

2 
CREATE TABLE `log` (
  `logid` bigint(20) NOT NULL AUTO_INCREMENT COMMENT 'The log ID',
  `logdate` datetime NOT NULL COMMENT 'The log date',
  `type` enum('error','audit') NOT NULL,
  `page` varchar(50) NOT NULL,
  `function` varchar(50) DEFAULT NULL,
  `message` longtext NOT NULL,
  `RequestUri` varchar(2000) DEFAULT NULL,
  `RemoteAddr` varchar(254) DEFAULT NULL,
  `userID` int(11) NOT NULL DEFAULT '0',
  `UserAgent` varchar(254) DEFAULT NULL,
  `scheduleID` int(11) DEFAULT NULL,
  `displayID` int(11) DEFAULT NULL,
  `layoutID` int(11) DEFAULT NULL,
  `mediaID` int(11) DEFAULT NULL,
  PRIMARY KEY (`logid`),
  KEY `logdate` (`logdate`)
) ENGINE=MyISAM AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;

That’s from 1.4.2 but I think should work.

As a side note, the volume of messages being logged is because you have auditing turned on on the CMS. Turn that off unless you’re troubleshooting an issue.

Later CMS versions have “maintenance” which will keep those tables at a reasonable size. Unless you have a compelling reason to stick with 1.4.1, then you should look to upgrade to something more recent as a priority. 1.7.9 is the latest stable release.

3

Alex,

Thank you. This is exactly what I needed, and it fixed our issues.

I realize we need to upgrade up to 1.7.9, however I have not had the time to perform this task yet. I will be looking to upgrade this soon.

Thanks again.