fenway

You talked about different permissions, etc. -- but you'll need a common login to all DBs, or manage multiple for each, which is difficult (though not impossible) to manage from the application code.

You can definitely stick to "standard" column names, syntaxes, etc., but there always will be DMBS-specific extensions, so be wary.

It's just alpha-transparency that's an IE issue.

You can also use + INTERVAL X SECOND... but that's much worse, and probaly not at all what you want.

Well, regardless of whether or not you insert, you can always find the matching value.

Depends... as "strings" or as identifiers?

No kidding! I've never even though of doing that... I guess that *does* work. I didn't say it wasn't allowed, just that there wasn't a "move" option. But it appears that you can simply move a column with really changing anything else about it. I haven't delved to see whether or not any indexes involving this column are rebuilt, either. BTW, this seems to work in v4.1 too. You learn something new every day -- that being said, why bother?

That's depends if you need to pull them all together or not.

NOT IN() is just plain bad... no index usage. But with a left join, you won't need either.

I've never seen such syntax... you can definitely create NEW columns BEFORE/AFTER existing ones.. but you can't move them at all (nor do you EVER have to).

That's what I thought. Even though that subquery really shouldn't be dependent on the outer one (since the where clause checks an inner table field, correct?), that NOT IN means it has to run that every time, AFAIK. That's probably why it's so slow. You'd be better off with a LEFT JOIN.

Can I see the EXPLAIN for that query/

Yes.. otherwise you could never use it in PHP!

It could still be wrong... check the grants table, make sure you're connecting from the right host. Make a new user, with no IP restriction (%), test that one.

Every DB has a way to "escape" keywords.

Why not use the first part, but in two parts?

You have line with mysql_query() and die()... just make sure you echo the SQL statement with the die(), and include some text to locate the error.

Or look at Ma'atkit.

In this particular instance, it has to stay within excel... but that module might come in handy another time.... Any other takers?

What do you get now?

You either have the wrong password or you're connecting from a new host.

Because it's a band-aid solution -- I wouldn't allow anyone to use reserved keywords in MY framework. But if you're not suck a stickler, go right ahead. I'm just tired of having columns named "date", "time", "desc", etc.

hold on a sec... did you say access?

I'm pretty good with excel, but not with VB script. I have a drop-down list populated from a named range (say, of names). Upon selecting a name from this list, all of the other fields on the page get updated from the master worksheet. Here's the goal -- I want to be able to print off a copy of the updated values for each person in the dropdown with one click of the button. There are 50+ people, I don't want to have to click the drop-down each time, hit print, and repeat, 50+ times. Seems like it should be easy to do with a script that either (a) iterates though the list and prints each one or (b) iterates through the list, makes a new sheet in a new workbook with the values only (no references), and then print that entire temporary workbook, with 50+ sheets. Personally, I think (a) is very easy, but I'm sure screen updates and print queues are invovled. HELP! ???

Not really -- why go looking for problems? Name your columns with underscores so that you won't ever run into this issue, and you're done. No backticks that mask potential problems.