fenway

"LOCK TABLES" isn't valid mysql syntax -- it's LOCK TABLE -- so I'm confused.

And post the working query.

Then you'll probably be ok.

It's close implicitly because the php thread terminates.

I'm confused... to use INSERT INTO... SELECT, you need to specify the column names for the insert table -- so (a) they shouldn't be quoted and (b) it can't possibly make sense to use variables here. My guess is you want: $add_info = "INSERT INTO $Log_tbl ( Uname,CurDate,StartTm,EndTm,IPadd ) SELECT Uname,CurDate,StartTm,'$EndTm',IPadd FROM $Active_tbl WHERE $Active_tbl.Uname ='$UserID'";

Nice... didn't even realize that was the point of the query ;-)

Just remember that even though VARCHAR is better than TEXT, any temporary table operation (e.g. filesort from grouping/ordering, subqueries) will silent convert VARCHAR to CHAR, so it will take up the maximum amount of bytes! So use the "full length" with caution

Yeah, drop the parens... I assume that worked.

Impossible to say with so little info... but I wouldn't worry about it.

Are you sure you've configured PHP accordingly?

Like with INSERT INTO ... SELECT WHERE?

the first two NULL keys suggest otherwise.

It's just that MySQL handles TEXT fields very poorly... if you must have them, consider have them in a separate table, or at the very least, not retrieving them with * ever.

Sounds like something a basic tutorial (like the ones of phpfreaks) could cover... anything specific?

Yes, I believe that it does... there would be no reason to update the indexes until you were "done".

Yup.

Show us the query.

Yes... please DO NOT store <BR> in the DB.

Yeah, no valid syntax there.

I'm sorry, whats the DB issue?

You should be converting your dates to proper SQL-99 format: YYYY-MM-DD. STR_TO_DATE() can help you.

It will do it on each row unless you use LOAD DATA... but you can DISABLE KEYS and/or LOCK the tables, too.

What?

Can't that be written as a left join? NOT IN is bad for performance.

Sorry, now you've lost me completely.