Member Avatar for trudge

I've got a Perl script that lets a client of mine dump and restore his inventory database. It has worked fine for years, only I recently noticed strange file results. Instead of dumping the data to the file, I found this (I've munged the db name):

-- MySQL dump 10.10
--
-- Host: localhost Database: xxxxxxxxxxxxxxx
-- ------------------------------------------------------
-- Server version 5.0.27

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;

NO DATA IS INCLUDED IN THIS FILE.

Previous dumps had this as the first line:
-- MySQL dump 8.23

Now I'm stuck with a problem. Do I now have to figure out the proper arguments to call mysqldump with, or should I use alternative methods to get a backup of this database?

Anyone else run into this and would like to share their solution?

  • 1 Contributor
  • 1 Reply
  • 100 Views
  • 1 Week Discussion Span
  • Latest Post Latest Post by trudge
Member Avatar for trudge

It turns out my host *did* upgrade the MySQL server, but somewhere in the re-start my script lost 'LOCK TABLE' permission, which thus rendered my script broken. I wasn't impressed, but for all intents and purposes, this thread is now solved.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.