PFMaBiSmAd

A) Does any php code run correctly on your localhost development system? B) The symptom is typical of php code using short open tags (which code that is intended to ever be published and distributed should never do.) What does the php source code of the file look like?

To start with (I don't know if this is all the errors in the query), this - l.SUM(quant) Should be something like - SUM(l.quant) And if you echo mysql_error() when your query fails, mysql/php will help you find where and why the query is failing.

desc (the starting position in the query that is displayed in the error as the to use near '...) is a reserved keyword - http://dev.mysql.com/doc/refman/5.0/en/reserved-words.html

If you record the datetime of submission (with each submission, which you probably already do), rather than attempt to keep a count, you can simply do a query that counts the number of submissions over a datetime range that you pick.

The following is some basic code that does what you state, but using a temporary table in the database. I tested this using a small set of data. You should test it first with an offline copy of your database to see if it has any performance problems and also have a known good backup of your online database before you attempt to run it online - // create the temp table $query = "CREATE TEMPORARY TABLE temp_table (userid INT, timestamp INT)"; mysql_query($query); $max = 600; // the maximum number of rows to keep for each user // get a list of userid's that have more than $max rows - $query = "SELECT userid, count(*) AS cnt FROM your_table GROUP BY userid HAVING cnt > $max"; $result = mysql_query($query); // get the $max'th row for each of those users into a temp table (rows start at zero so this actually gets the first row to be deleted) while($row = mysql_fetch_assoc($result)){ $query = "INSERT INTO temp_table (userid,timestamp) SELECT your_table.userid, your_table.timestamp FROM your_table WHERE userid = {$row['userid']} ORDER BY timestamp DESC LIMIT $max,1"; mysql_query($query); } // delete the rows with the same and older (smaller) timestamps $query = "DELETE t1 FROM your_table t1 INNER JOIN temp_table t2 WHERE t1.userid=t2.userid AND t1.timestamp <= t2.timestamp"; mysql_query($query);

We would need to see the actual code in testwysiwyg.php that is producing the error on line 4. That's not it.

Yes, did you read them, because they tell you what the problem is. The filename (in $testimony) is empty. Wherever you are defining $testimony at is not in the same program scope as the php code that is using $testimony.

What you are doing in not clear and what you have shown makes no sense (it also violates one of the prime rules of programming, the separation of code and data. Your data should not contain code.) You can use a variable as the argument that the include statement operates on and the code (the include) does not need to be part of the data.

There is nothing technically wrong with that query. It would take seeing an example of data in the datetime column that you expect to be returned and what the column definition is for anyone to have a chance at telling you why nothing is being returned. Also, how did you execute this query and display the results or otherwise determine that there were no matching rows returned? Edit: Also how is the query being produced, because something like a non-printing character, such as a newline or a null, as part of the '2010-01-01 00:00:00' ... values would prevent a match.

The point of echoing the actual query so that you can see exactly what it is, was so that you can determine what is wrong with it in order to fix it. Without seeing what the result of doing that is, no one can help you.

That's part of the LIMIT term. I would form the query string in a php variable and then echo it so that you can see exactly what the query contains.

The error message is probably the most common one seen concerning code that is using a database. It means that your query failed to execute and it returned a FALSE value instead of a result resource (i.e. mysql_fetch_assoc(): supplied argument is not a valid MySQL result resource.) It also means that your code does not have any necessary error checking and error recovery logic in it to check for errors and prevent the remainder of the code that is dependent on the result of the query from blindly executing, nor does your code have any error reporting logic to tell you that the query failed and why it failed. For debugging purposes, get mysql to tell you why the query failed by echoing mysql_error() on the line right after the line with the mysql_query() statement.

The default password is probably nothing (you would use an empty string as the password value.) You can set a password as documented on the xampp site - http://www.apachefriends.org/en/faq-xampp-windows.html#password1

It's limited by how many session data files the operating system will handle in one folder or the total of that number in each folder if you use the optional N argument on the session.save_path setting.

Someone already answered that -

Nope, that's not even a URL. It's an image resource returned by a GD library function.

You cannot output image data directly on a HTML page. You must use an <img src="URL of an image" alt=""> HTML tag for each image you put onto a HTML page. The 'URL of an image' that you put into the src= attribute must be to your .php script that outputs the Content-type: header, followed by the image data.

The query that had 'NULL' (a string enclosed in single-quotes) would result in a zero being inserted into a numeric column because the string will be converted to the 'best' numeric value, a zero.

The sql in the later post is missing some of the characters because they were converted to smiley figures because the code was not posted inside of ... tags. The sql error means that you attempted to execute the PHP code that you posted (the $sql = array(.. .. ..); statement) directly against your database as though it was sql statements. You would need to just use the sql statement - CREATE TABLE SHOUTBOX_TABLE ( shout_id MEDIUMINT( UNSIGNED NOT NULL auto_increment, shout_username VARCHAR(25) NOT NULL, shout_user_id MEDIUMINT( NOT NULL, shout_group_id MEDIUMINT( NOT NULL, shout_session_time INT(11) NOT NULL, shout_ip CHAR( NOT NULL, shout_text TEXT NOT NULL, shout_active MEDIUMINT( NOT NULL, enable_bbcode TINYINT (1) NOT NULL, enable_html TINYINT (1) NOT NULL, enable_smilies TINYINT (1) NOT NULL, enable_sig TINYINT (1) NOT NULL, shout_bbcode_uid VARCHAR(10) NOT NULL, INDEX (shout_id) )

Ok, new guess, since the symptom just showed up after a number of years of the site working correctly. Something was changed/upgraded and the versions of php and the Hardened php patch are not the same, resulting in the values being overwritten. The Hardened php patch can USE the remote_addr for generating session id's... It's remotely possible that a version mismatch between the patch code and the php code is causing the values to be overwritten.

If your column is using the AUTO_INCREMENT attribute, you won't have any problems like this.

You need to use just the date part of the value - ORDER BY DATE(date_completed) ASC

You have a $ sign in front of the $getuid_nick() function call, making it a variable-function-name (php expects a variable named $getuid_nick that holds the actual function name to call.)

Based on your table definition, any query that does not supply values for the NOT NULL columns will fail (just tested), unless you use the IGNORE keyword or strict mode is off, in which case NULL's will be inserted into the default NULL columns and zero values will be inserted into the NOT NULL columns (just tested as well.) All the queries posted in this thread are likely failing and any rows you have that are showing you a zero value for the customer_id were probably already in your table from previous testing.

I doubt it. What is your table definition and what is your code that is retrieving and displaying the value?