Dear All,

I found the following error after I moved my database from one server to another server.

DBSQL (14667): Fatal Error: Unable to execute query: UPDATE Links SET isNew = 'Yes' WHERE Add_Date > '2000-03-18' . Reason: Table 'Links' is read only at /home/xxxx/cgi-bin/xxxx/xxxx/nph-build.cgi line 171

For help, please send mail to the webmaster (root@localhost), giving this error message
and the time and date of the error.

The method I used to move the database is just download all files in the old server and then upload to it. I used the same file permission but I don't know it said this error.

Is there any way that can fix the problem?




------------------
Bear EveryWhere

 
Your MySQL table does not have "write" enabled in the permissions for the user that is attempting to access it. You need to go into the "mysql" database, and check your user permissions....

This is _NOT_ a Links problem, it's a MySQL configuration error.

ADDT'l: IF the old server is one you still have access to, and it was just an upgrade for you, copy the mysql tables over (stop the server, copy the tables, restart the server) and you should have your old user access permissions as well -- and all the old security holes, users, etc. UNTESTED!!! If you moved from one ISP to another, you need to make sure your user ID has read/write/update/etc permissions to the Links database & tables. Don't forget if you are running your own servers to restart the MySQL damon or re-read the permissions files whenever you make a change to a user or password! This is a _real_ source of frustration, since everything looks like it's workiong, except the running copy of MySQL doesn't know you've made user-permission changes.

[This message has been edited by pugdog (edited March 26, 2000).]

I would use:

mysqldump --add-drop-table -uUSER -pPASS YOURDATABASE > backup.txt

to get your current database, and then ftp over the backup.txt file and type:

mysql -uUSER -pPASS YOURDATABASE < backup.txt

on the new server. This will recreate everything, and you don't need to worry about different operating systems/etc.

Cheers,

Alex

Granted! I keep forgetting mysqldump, because I use a shell to access MySQL. And, because I'm all Solaris 7, I _can_ copy files from one area to another and make them work. Same should be true for anyone using the same versions of Linux and builds of MySQL, or moving from BSD system to another, etc. But, it's a risk! Since the internal data representation of the files is system-dependent, and the mysqldump is a system-independent ascii based dump file.

But, it still wouldn't answer the "permissions" problem, since a user in the new installation would have to have access to the new database that was imported. "root" should have full access to everything, but not everyone uses the root password for the database tables -- and that is a good idea! <G>

The permissions problem is probably because he copied the mysql data files, and did not set the permissions properly. For instance on one machine mysql may be running as root and the data files are owned as by root and chmod'd 600. On the other machine, mysql may be running as a user 'mysql' so when you copy the files the new mysql can't read them.

Other situations are peharps the file permissions were set improperly when copying, etc. This is one reason to use mysqldump, you don't need to worry about shutting down mysql (it locks the tables), and it will work across any platform (i.e. transfer your database from your isp to a windows platform at home).

Cheers,

Alex