fenway

That's very strange.... but at least date should be listed in possible keys?!?

Why are you display all the login/pass data? The way I do this is to search on username, and then get back the ENCRYPTED password and check.

You'll need to join all three tables together: select c.* from students as s inner join students_classes as sc using (studentID) inner join classes as c using (classID) where s.studentID=<yourID>

Could you post your solution for the benefit of others

Just looking over your command again: mysql -u user -p pass database_name < file.sql There shouldn't be a space between -p and pass; or you can use --password=pass. But typing the password in plaintext like that isn't secure -- see here. That will probably fix it... but I'd specify the full path to the .sql file just to be sure. Personally, I prefer the --user=user_name --password=pass --database=dbname format. You can also redirect the output to a text file so that you can see what's going on.

If you have INSERT statement, you basicallly have to run the SQL commands... but it shouldn't make any difference if you have "ssh" or "shellscript" or "modes".

All of those have nothing to do with mysql... that's php variable interpolation & parsing. Just be sure to escape mysql special characters.

Then you'll need a LEFT JOIN instaed.

sorry it was a typo, though even removing b.id in the GROUP, staying only c.blogid the query takes 0.2 secs to run, and second one takes 0.0 I'd like to see that EXPLAIN... I find it hard to believe that it's still won't pick up "date" as a possible index row for use to prevent the filesort. However, because you're grouping from one table and ordering by another, your subquery version may in fact be better in this particular case.

There is, but there shouldn't be... it shouldn't matter to you, either, or you're using the ID field for something you're not supposed to be using it for

You need to do this in two steps... first, get the unique jobs with the most recent date... then join this derived table back.

That's one way... I prefer writing it as a cross join an moving the condition to the where clause, but that's just me. You can use an IN() clause with HAVING & COUNT(), but depending on which version you use, it may not use indexes efficiently.

This is degenerating into a php-only problem... if it's not solved soon, I'll move it.

Echo the query itself.

Sorry, I didn't see that group by for "FIRST" -- why two columns there?

Assuming you mean that each type has its own details table, it's not easy to magically determine the table name of your related table...

There must be other fields, though... you'll need profileID (which I assume is the "user") and date just to get the most recent, which leaves only the surrogate PK?

Did you try just connecting with the user & pass?

Alternatively, use a collation that is case sensitive.

What help screen?

I told you precisely what to fix. This field doesn't exist: GetSQLValueString($_POST['Sex'], "text") Switch it to GetSQLValueString($_POST['Gender'], "text")

When you make a derived table, that join has no index to use... but like you did in the "FIRST" query, the correct way is with a LEFT JOIN directly, not via a derived table. The "SECOND" query uses a dependent subquery, which is worse than "FIRST" -- but it looks like you've added an index on date, which makes it "look" better. Re-run the "FIRST" query -- it's the best way to go.

That's the "idea"... but to use the non-PK is completely incorrect.

Is this your server or not? Can you still log in directly, not via phpmyadmin?

That's because you're not retrieving anything from the SELECT widget named "Gender"... look at $insertSQL!!!!