fenway

Let's agree to disagree.

So close -- echo that string -- I still see php variables.

There's a sticky in the configuration child board about this.

Regarding the insert-- that's impossible -- you must be querying a different DB. Run a DESCRIBE to confirm. Regarding the select -- that must be imposed by your PHP driver.

I simply meant that LIKE '%str%" doesn't take advantage of any index.

You'll need a regex UDF or post-process in PHP. Or do a really-quick-and-dirty string replace, and compare pre- and post- lengths.

What the "queue to the database"?

You'd have to pass these values via the URL.

It would be preferable to compare them in mysql directly -- if you have a unix-timestamp on one side, then use the corresponding mysql function to convert the other side.

Not that it's particularly efficient....

If you'd like to create a constant to store "1", then name it $ONE. Otherwise, name it to describe "1 what"?

Actually, the 7 different versions of regex string functions in PHP is, IMHO, a "horrible error". The value is not the same as the contents -- 1 is meaningless -- one what? Again, this is my personal preference from 20+ years of programming experience -- people can do whatever they want.

Look at each of the fields returned -- one of them is what you're looking for.

Or you use a REGEXP to check for a alphanumeric character...

Huh? What's the "middle of the table"?

Don't name based on "value" -- named based on "contents". In your example, what does "1" represent? Purpose is subjective, and hence subject to change. You don't want to ever have to change the variable names - EVER. And yes, if SQL goes away, then I would really hope that you weren't expecting to use code that required it -- but that doesn't make the variable that contains the SQL any less valid.

Sounds like a job for a LEFT JOIN... IS NULL.

I don't download random files -- but if it's a true CSV file, then the refman says: LOAD DATA INFILE 'data.txt' INTO TABLE tbl_name FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '\r\n' IGNORE 1 LINES;

Looks like a unix-timestampl

Maybe I'm missing the results you're getting now vs. what you want.

Running raw, arbitrary, user-contributed SQL queries is dangerous.

DISTINCT has nothing to do with sets -- you can ask for a subset of fields from "unique" rows that have duplicate tuples -- nothing violates SQL. DISTINCT is evil because it's a very poor workaround to GROUP BY. It doesn't do anything differently, but it can easily be misconstrued as a function call - I've seen it many times on this forum. You're allowed to write "SELECT DISTINCT *" with a GROUP BY clause -- that's just evil. As for tables allowing duplicates, that up to you, the DBA, when you inserted the record -- if you choose a truly UNIQUE value, with a unique constraint, you won't get so-called duplicates.

Though is could be re-written as a join, too, since large IN() clauses aren't optimal.

Performance-wise, the GROUP BY is ill-advised -- but as you mentioned, if the query needs back more data, that would be the easy workaround. Of course, it would be preferable to run two queries in that case.

Actually, I don't -- find where you execute your query, and check for errors.