bubblegum.anarchy

To resolve any issues relating to encryption functions that might contain arbitrary byte values.

Like Paul stated - the first insert query is setting the id to NULL and as a result is also setting the last insert id to null to, there is no need to explicitly assign an auto increment value through the insert statement, the id value will be generated automatically... remove the first NULL from the first set of inserted values and use last_insert_id() in the last set.

The error suggests a credentials issue, try swapping login for root.

I mean, according the query I have written there It removes all the records except the first occurrence of each unique ip .As each ip has a unique id and rank so it will keep the records of unique (id, rating, ip) combination. webosb original post does not mention that each ip has a unique id - but does mention that the ids range from 1 - 1000 and rating range from 1 - 10.

Though this has nothing to do, directly, with your actual question, SA - would adding an additional indexed enum column named `range` with values such as 0-5, 5-10, 10-5 (depending on application) improve your query performance?

?

Consider a query that will collate all the information in the following format: Movie | Date | Session Times ... and display the results in an order fashion using PHP. Use GROUP_CONCAT for the session times, depending on how the session times are stored.

Try... date_format(date_purchased, '%Y-%m-%d') = CURRENT_DATE

Grab all the records on the condition of the 'certain day' ordered by the date and limit 1.

What is this: 'CURRENT_DATE():00:00:00'

$sql1 = "SELECT customers_email_address, date_purchased, order_total FROM orders WHERE customers_email_address = '$_POST[myemail]'"; The MySQL query starts at the end of $sql1 = " and ends at "; - everything between the quotes is the MySQL query

Slight change: SELECT crn.id, person.fname FROM crn LEFT JOIN instructor_crn ON crn.id = instructor_crn.cid LEFT JOIN person ON person.id = instructor_crn.person WHERE crn.id = '6' Should be fine... change the LEFT JOIN to INNER JOIN if a matching record must exist.

The PHP processor does not understand MySQL functions. The PHP forum may be more appropriate for PHP related issues.

SELECT * FROM postcodes WHERE start = 'SW1'; is much faster than SELECT * FROM postcodes WHERE postcode LIKE 'SW1%' I suggest you stick with the original system.

This has nothing to do with the error, but what does the paranthesis wrapping the first join mean? Might be missing the .user_id on the GROUP BY GROUP BY moch_dueno.user_id

At a glance: Wrap if conditions in paranthesis and add a variable identifier to order_title and date_purchased, and I do not think CURDAT is anything in PHP

webosb wanted a unique (id, rating, ip) combination.

Is the following a good idea, fenway: ALTER TABLE account MODIFY password VARBINARY(100) not null default 'password' comment 'account password';

nope, I am lazy like that - and have moved on in code since discovering the error... also, binindex confirmed that later versions are fine.

oh yeah... but take a look at this... SET @date_created = '2007-06-01'; SELECT benchmark(10000000, month(@date_created) = month(CURRENT_DATE)); # ~ 2719ms SELECT benchmark(10000000, @date_created BETWEEN last_day(CURRENT_DATE - interval 1 month) AND last_day(CURRENT_DATE)); # - 297ms I must have previously not run the SET line... *slaps head*

I have never had a problem using a varchar column for encrypted data, besides BLOB holds a variable amount of data anyway or use VARBINARY instead.

md5() should be used instead of password() to encrypt data, from mysql documentation: Note: The PASSWORD() function is used by the authentication system in MySQL Server; you should not use it in your own applications. For that purpose, use MD5() or SHA1() instead. Also see RFC 2195 for more information about handling passwords and authentication securely in your applications.

SELECT * FROM repository WHERE name LIKE '%steph%' % = wildcard http://dev.mysql.com/doc/refman/4.1/en/string-comparison-functions.html

Um, yeah. Which is exactly why I said his statement about there not being a common element between the tables was false. I think the OP was thinking there had to be "the same" common element between all the tables, and that is not the case. Please excuse me, my comment was meant for the original poster and meant no offense.

Still looks like joins to me.