mysqldba

Oh, and the opening tag on line 1 of news.php doesn't look right, either

In add.php, line 2: <form action="<? $_SERVER['PHP_SELF']; ?>" method="POST"> The use of short form of PHP opening tags is deprecated, and has been removed entirely from the latest PHP versions IIRC. Try: <form action="<?php print $_SERVER['PHP_SELF']; ?>" method="POST">

http://uk2.php.net/addslashes ? i.e. addslashes( $row['title'] )

Provided you don't have any TIMESTAMP fields, the data should be unchanged (provided the column type definition remains the same)

Why would you want to do that? If you need the columns returned in a different order for SELECT statements, just name the fields in the right order - relying on field order in the table is just setting yourself up for a future FAIL. You can reorganise the table without deleting any data, but there's a very good chance that the MySQL server will lock the tables while it's sorting things out - just to warn you. With no schema posted, I'll have to demonstrate with an example table: mysql> CREATE TABLE bob (a INT, b VARCHAR(3), c DATETIME); Query OK, 0 rows affected (0.04 sec) mysql> DESCRIBE bob; +-------+------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-------+------------+------+-----+---------+-------+ | a | int(11) | YES | | NULL | | | b | varchar(3) | YES | | NULL | | | c | datetime | YES | | NULL | | +-------+------------+------+-----+---------+-------+ 3 rows in set (0.01 sec) mysql> ALTER TABLE bob MODIFY b VARCHAR(3) AFTER c; Query OK, 0 rows affected (0.02 sec) Records: 0 Duplicates: 0 Warnings: 0 mysql> DESCRIBE bob; +-------+------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-------+------------+------+-----+---------+-------+ | a | int(11) | YES | | NULL | | | c | datetime | YES | | NULL | | | b | varchar(3) | YES | | NULL | | +-------+------------+------+-----+---------+-------+ 3 rows in set (0.01 sec) You need to use ALTER TABLE ... MODIFY to do the edit. You're effectively redefining the column, so make sure your new definition is the same as the current one (SHOW CREATE TABLE is useful here)

Does the user that the MySQL server runs as have write permission to that directory?

Most languages have the option to use 'persistent' connections - this is where a connection to a MySQL server is kept open, even after the script has finished executing. This can be useful to (usually marginally) speed up a script, as the next time the script is executed the MySQL server connection attempt is quickly handed the existing connection. The down side to this is that by holding the connection open, it uses up one of the available connection slots on the MySQL server and so could potentially block another connection attempt (the MySQL server does not have a LRU disconnection policy). As for your "Too many connections" problem, it could be one of three things: 1) The server has too many open connections already. A MySQL server can only handle a specific number of open connections before refusing to allow any more, and this limit is shared amongst all users of the server. It's usually set quite high, although it's easily possible for someone to effectively DoS a MySQL server by making lots of connections (but see below) 2) Your user account has a limited number of connections allowed per hour - any further connections within that hour would be rejected. This is set on a per-user basis. 3) Your user accounts has a limited number of allowable open connections - any further connections would be rejected. This is set on a per-user basis. It's always important to read the error message you get returned on the connection attempt, as in most cases this will pinpoint the exact reason for failure. If your account has a maximum number of connections limit (scenario #3), the error would be: ERROR 1226 (42000): User 'mysqldba' has exceeded the 'max_user_connections' resource (current value: 1) Where 'mysqldba' would be your username, and the 'current value' is the maximum number of open connections allowed from this user. If you account has a maximum number of connections per hour limit (scenario #2), the error would be: ERROR 1226 (42000): User 'mysqldba' has exceeded the 'max_connections_per_hour' resource (current value: 1) Where, once again, 'mysqldba' would be your username, and the 'current value' is the maximum number of connections per hour allowed for this user. The error message you got (code 1040) indicates that the entire MySQL server has run out of connection slots - this is the DoS scenario I mention above. What can you do about it? From what you've said, you don't have superuser privileges on this server, so nothing, apart from complain to the SysAdmin responsible for that server. They might increase the maximum number of connections allowed, which could solve the problem short-term, but if someone else using the server is creating a stupid number of database connections the slots would just fill up again. What they probably should do is to also enforce a per-user maximum open connection limit as well - this would stop the heavy users clogging up the server. In a shared-server situation like yours, this would make the most sense - 'power users' would/should have their own server, or could/should pay to increase their maximum open connections.