Hot answers tagged mysql-5.5
The values seem to be Unix timestamps, stored as strings. You can use the special datetime functions that MySQL has for conversions: SELECT * FROM representative WHERE DATE_ADD(FROM_UNIXTIME(lastLoginTimestamp), INTERVAL 7 DAY) >= NOW() ; but it won't be very good for efficiency. Much more efficient, if there is an index on the column, to do it the ...
update mytable set myfield1 = replace(replace(replace(replace(replace(myfield1, '…' ,'-'), '?' ,'|'),'”' , '"'),'‘' , '`'),'?' ,'"');
select from_unixtime("1427162434"); the rest you will figure out but consider formatting the historical data and just change the type and test. Can't believe that the dates are pushed to the DB as chars.
The database server that you are accessing using phpmyadmin and the mysql monitor (command line client) are different. If you look at the versions, phpmyadmin is accessing a 5.5.1-m2-community version, while you are accessing 5.6.17-community on the command line. Either you are accessing a remote server or you have two separate installations of mysql on the ...
Your first HUGE mistake (as @ypercube pointed out) is not using a DATETIME type for a date-time type variable. TIMEs are not VARCHARs and doing this will mess up your queries, make your app non-portable and will confuse the optimiser. The other HUGE problem is MySQL. It doesn't perform this sort of query properly. Your query is ambiguous - PostgreSQL for ...
It turned out to be an issue with our Proxy Server, blocking downloads from percona.com Running sudo apt-get update revealed that every connection to percona.com 'failed', and so I got that added to the approved list, and after that it installed fine.
Only top voted, non community-wiki answers of a minimum length are eligible