fenway

What a mess.... store integers as INT.

Did you check mysql_error()? "date" is a reserved keyword...

SET is quite evil... not very flexible, not easy to query / edit, etc.

PASSWORD() is not meant for public use -- it's MySQL's internal hash algorithm. Use MD5() or equivalent instead.

Agreed... but it's easier to replace with a whitespace on output.

Then explain what you actually want to do.

Since there's no sql anywhere to be seen, this topic is in danger of being moved to another forum.

What does mysql_num_rows() have to say? No error messages?

And no 1-800 number.

Really depends how much of your data your analyze at one time... if it's about 30% of the table, mysql won't use an index regardless, archive or not

Me neither... never used another domain registrar other than them. And they didn't hold an expired domain hostage at all... almost unheard of these days.

"Show content" isn't a DNS issue.. it just deals with IP mappings. If your host's DNS is problematic, use another DNS server.

No, you should NEVER do that... good luck if you ever change the order of the fields or add a new one! That's the only reason I don't like this syntax :-(

Then either you're not connecting to the right DB, or your code isn't iterating over the rows (your initial code didn't)... but I've been assuming you've followed other suggestions. Post your code.

Lists don't belong in fields, they belong in separate records. Pictures (binary data) is best stored on the filesystem, though it's technically possible to store it in the DB.

I suppose so.. as long as your query will use some sort of index, you'll be fine... incidentally, you might want to look at the ARCHIVE table type as an alternative.

Could you post your current query, some same output, and the desired output?

If that's true, then there is only one e-mailID that satifies your WHERE clause. Drop the WHERE clause, see what happens. It's not MySQL, it's the data.

The latter is more useful, because you can create multi-valued insert statements. The only reason the former exists is for compatibility and similiarty to the update syntax.

Hard to imagine how you're working with a table without a PK... unless you truly have another unique identifier across multiple columns...

This is a continuation of this double-post. What NEWID()? TOP 1 is MS-SQL, not MySQL.

Don't double-post!

I'm sorry, what do you want to do?

This is a continuation from this thread... you're obviously confused about PK and UID, since they should be one and the same. You don't sort the data, you sort the output!

One of the few reasons to actually upgrade (other than index merge).