1
Hi gang - sorry if this is in the wrong section or even inappropriate for these Forums but it is related to the the database that I use for my XOOPS site......
The following is the first few lines of a PhpMyAdmin databse dump:
-- MySQL dump 10.9
--
-- Host: localhost Database: databasename
-- ------------------------------------------------------
-- Server version 4.1.20
/*!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 */;
/*!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 */;
--
-- Table structure for table `wibble_avatar`
--
DROP TABLE IF EXISTS `wibble_avatar`;
CREATE TABLE `wibble_avatar` (
`avatar_id` mediumint(8) unsigned NOT NULL auto_increment,
`avatar_file` varchar(30) NOT NULL default '',
`avatar_name` varchar(100) NOT NULL default '',
`avatar_mimetype` varchar(30) NOT NULL default '',
`avatar_created` int(10) NOT NULL default '0',
`avatar_display` tinyint(1) unsigned NOT NULL default '0',
`avatar_weight` smallint(5) unsigned NOT NULL default '0',
`avatar_type` char(1) NOT NULL default '',
PRIMARY KEY (`avatar_id`),
KEY `avatar_type` (`avatar_type`,`avatar_display`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
--
-- Dumping data for table `wibble_avatar`
--
/*!40000 ALTER TABLE `wibble_avatar` DISABLE KEYS */;
LOCK TABLES `wibble_avatar` WRITE;
UNLOCK TABLES;
/*!40000 ALTER TABLE `wibble_avatar` ENABLE KEYS */;
Basically, when I try to get this database dump written to a new database it seems to fail at the first table, i.e. wibble_avatar (wibble is not the real db table prefix
)
I get an error message which says:
#1044 - Access denied for user 'database'@'localhost' to database 'database'
I don't recall seeing the "LOCK TABLES" code before and I'm sure the inability to write to the new database is connected with this.
All advice gratefully received - many thanks
