“unknown table status: TABLE_TYPE” and related messy stuff over mysql phpmyadmin 4.4.14 (X.A.M.P.P. 5.6.14-0-VC11, Windows 7 x64) - mysql

Already existent related question topics are useless, since it's a different (or even older -3.40-) version. So .patches don't even fit in files described in other posts around the web.
In addition to unknown table status these notices also appear every time I click over a non empty table:
Notice in .\libraries\tbl_info.inc.php#78
Undefined index: Rows
Backtrace
.\libraries\Menu.class.php#221: include(.\libraries\tbl_info.inc.php)
.\libraries\Menu.class.php#85: PMA_Menu->_getBreadcrumbs()
.\libraries\Response.class.php#308: PMA_Menu->getHash()
.\libraries\Response.class.php#388: PMA_Response->_ajaxResponse()
PMA_Response::response()
Notice in .\libraries\tbl_info.inc.php#80
Undefined index: Name
Backtrace
.\libraries\Menu.class.php#221: include(.\libraries\tbl_info.inc.php)
.\libraries\Menu.class.php#85: PMA_Menu->_getBreadcrumbs()
.\libraries\Response.class.php#308: PMA_Menu->getHash()
.\libraries\Response.class.php#388: PMA_Response->_ajaxResponse()
PMA_Response::response()
Notice in .\libraries\tbl_info.inc.php#78
Undefined index: Rows
Backtrace
.\libraries\Menu.class.php#221: include(.\libraries\tbl_info.inc.php)
.\libraries\Menu.class.php#72: PMA_Menu->_getBreadcrumbs()
.\libraries\Response.class.php#315: PMA_Menu->getDisplay()
.\libraries\Response.class.php#388: PMA_Response->_ajaxResponse()
PMA_Response::response()
Notice in .\libraries\tbl_info.inc.php#80
Undefined index: Name
Backtrace
.\libraries\Menu.class.php#221: include(.\libraries\tbl_info.inc.php)
.\libraries\Menu.class.php#72: PMA_Menu->_getBreadcrumbs()
.\libraries\Response.class.php#315: PMA_Menu->getDisplay()
.\libraries\Response.class.php#388: PMA_Response->_ajaxResponse()
PMA_Response::response()
Any suggestion to avoid this annoying behaviour would be appreciated.
Thanks in advance.

This is an outdated phpMyAdmin version. The latest stable version is 4.5.1. In the latest XAMPP (https://www.apachefriends.org/blog/new_xampp_20151019.html) they mention updating phpMyAdmin to 4.5.0.2.

Related

mysql ON DUPLICATE KEY not recognized

This statement randomly stopped working. I believe it is because of a new version of WAMP I am using 4.5.2 .
INSERT INTO at_user_listing_settings (userID, rfID, userID_rfID, Watching) VALUES(177, 35888, '177_35888', '1') ON DUPLICATE KEY UPDATE Watching='1'
I get this error:
Unrecognized keyword. (near "ON" at position 138)
Unrecognized keyword. (near "DUPLICATE" at position 141)
Unrecognized keyword. (near "KEY" at position 151)
I cant seem to find anything wrong with the syntax, was ON DUPLICATE KEY changed or deprecated?
Finally figured this thing out.
When you download a new version of WAMP, it sets the mysql to "Strict" mode by default. My real server hosted by hostgator must have more lenient restrictions. When trying to run the code locally, the code was correct, but the sql statements were running into problems when trying to update or insert into the database (also local).
For example, Strict mode required columns with boolean values to have a default value. If any column did not have a default value it would fail when trying to insert. The worst part is it wont return an apache or php error, so it made it extremely difficult to debug. It also did not like "ON DUPLICATE KEY".
To solve this problem I went into the WAMP > MySQL > my.ini > and looked for sql-mode="STRICT_ALL_TABLES".
I then removed STRICT_ALL_TABLES, and everything started working like it was supposed to.
This would appear to be a phpMyAdmin issue!
See github errors that have been reported
It seems rather old, but I see no reference to a fix, and it is still OPEN
We provided an ADDON for a similiar tool called Adminer, SourceForge download link here as people were having a few odd issues with phpMyAdmin
Download that and it will install straight into WAMPServer and appear on the WAMPServer homepage in the "Your Aliases" menu
Simply rewrite your query to this:
INSERT INTO at_user_listing_settings
SET
userID = 177,
rfID = 35888,
userID_rfID = '177_35888',
Watching = '1'
ON DUPLICATE KEY UPDATE
Watching = '1'

ACL truncates action name

Using PhalconPHP framework
I have been using ACL successfully for a while but ran into an issue when I tried using an action name that was more than 16 characters long. When I add adminChangePassword as an access under my users resource | get the error
Access 'adminChangePassw' does not exist in resource 'users'
#0 [internal function]: Phalcon\Acl\Adapter\Memory->_allowOrDeny('Administrators', 'users', 'adminChangePass...', 1)
But using the name adminChangePassw works fine (apart from that it is a rubbish name). It appears that the name is being truncated at some point which I presume would be a bug.
Is that what is happening or can anyone give another explanation of this error?
A quick test
I've just tried adding an access in the users resource called 12345678901234567 and the error says that 1234567890123456 does not exist - truncating the last 7...
Occurs in tutorial programs
I tried adding 'adminChangePassword' to the ACL in my working Vokuro example and get the same error - so it isn't related to any changes I have made to how the ACL works.
This is because I had been working from the Vokuro example code - the database for which limits the size of the action and resource fields to 16 characters. Changing the database setup to allow more characters in those fields fixes the problem.

Missing Database Table Aro (expected "aros"), create it first

I have an application that uses Cake PHP and it does not want to run properly. I am getting numerous errors and do not even know where to start fixing it:
Notice: Undefined variable: permissions in
app/views/layouts/default.thtml on line 58 Call Stack: 0.0000 637384
{main}() /app/webroot/index.php:0 0.0022 892856
Dispatcher->dispatch() /app/webroot/index.php:84 0.0051 1104112
Controller->_initComponents() /cake/dispatcher.php:227 0.0051 1104616
Component->init() /cake/libs/controller/controller.php:271 0.0051 1105304
Component->__loadComponents() /cake/libs/controller/component.php:59 0.0054 1116768
AclComponent->__construct() /cake/libs/controller/component.php:124 0.0054 1116768
AclComponent->getACL() /cake/libs/controller/components/acl.php:56 0.0074 1543960
Model->__construct() /cake/libs/controller/components/acl.php:72 0.0097 1855456
Model->setSource() /cake/libs/model/model_php5.php:301 0.0103 1856912
Object->cakeError() /cake/libs/model/model_php5.php:518 0.0106 1885784
ErrorHandler->__construct() /cake/libs/object.php:169 0.0111 1892840
At the bottom it says:
Missing Database Table No Database table for model Aro (expected
"aros"), create it first. Notice: If you want to customize this error
message, create app/views/errors/missing_table.html.
Does anyone have an idea what is wrong?
You're missing a database table
It's looking for the table "aros" but can't find it. Create the table based on the ACL part of the CakePHP book.

max_allowed_packet=1024M... and it still gives me error "Got a packet bigger than 'max_allowed_packet' bytes query..."

I´ve just moved my Drupal site to a new managed VPS.
Each time I try to run cron, I get this nasty error:
Warning: Got a packet bigger than 'max_allowed_packet' bytes query:
INSERT INTO watchdog (uid, type, message, variables, severity, link,
location, referer, hostname, timestamp) VALUES (1, 'php', '%message in
%file on line %line.', 'a:4:{s:6:\"%error\";s:12:\"user
warning\";s:8:\"%message\";s:1582172:\"Got a packet bigger than
'max_allowed_packet' bytes\nquery: UPDATE cache_update SET
data =
'a:72:{s:10:\"admin_menu\";a:10:{s:5:\"title\";s:19:\"Administration
menu\";s:10:\"short_name\";s:10:\"admin_menu\";s:10:\"dc:creator\";s:3:\"sun\";s:11:\"api_version\";s:3:\"6.x\";s:17:\"recommended_major\";s:1:\"1\";s:16:\"supported_majors\";s:3:\"1,3\";s:13:\&qu
in /home/drupal/includes/database.mysql.inc on line 135
The thing is that I´ve set max_allowed_packet to 1024!
And still gives me that error.
That error seems to be related to the admin_menu module, but even after disabling that module, the error is still there (referencing other module) and after disabling that other module, the error is still there, and so on an on.
It seems that the problem is related to the mySQL table "cache_update" but I can´t understand what´s going on. Even after searching Drupal forums, I couldn´t manage to get to the problem. Just found some ways hacking core, wich isn´t good.
I´ve checked that max_allowed_packet syntax is ok in my.cnf file:
max_allowed_packet=1024M
I think this is a mysql specific issue, so that´s why I´m posting this here.
Thanks for your insight!
Rosamunda
Just in case anyone out there happens to be in the same situation, I´ve solved the error deactivating the update core module.
Have found the answer tying a lot of stuff that I´ve read out there, don´t remember where exactly I get the solution. But it works, at leat in my case it did.

Unknown character set index for field received from server

I have an instance of MySQL 5.0.4.1 with an application written in Hibernate. On one of the pages, I get the following error message in the server log:
Unknown character set index for field '123' received from server.at com.mysql.jdbc.Connection.getCharsetNameForIndex(Connection.java:1664)at com.mysql.jdbc.Field.(Field.java:144)at com.mysql.jdbc.MysqlIO.unpackField(MysqlIO.java:506)at com.mysql.jdbc.MysqlIO.getResultSet(MysqlIO.java:280)at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:1319)at com.mysql.jdbc.MysqlIO.sqlQuery(MysqlIO.java:1218)at com.mysql.jdbc.Connection.execSQL(Connection.java:2233)at com.mysql.jdbc.Connection.execSQL(Connection.java:2193)at com.mysql.jdbc.Connection.execSQL(Connection.java:2174)at com.mysql.jdbc.Connection.setAutoCommit(Connection.java:536)at org.apache.commons.dbcp.DelegatingConnection.setAutoCommit(DelegatingConnection.java:268)at org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.setAutoCommit(PoolingDataSource.java:293)at org.hibernate.transaction.JDBCTransaction.toggleAutoCommit(JDBCTransaction.java:194)at org.hibernate.transaction.JDBCTransaction.rollbackAndResetAutoCommit(JDBCTransaction.java:186)at org.hibernate.transaction.JDBCTransaction.rollback(JDBCTransaction.java:162)at org.springframework.orm.hibernate3.HibernateTransactionManager.doRollback(HibernateTransactionManager.java:603)at org.springframework.transaction.support.AbstractPlatformTransactionManager.processRollback(AbstractPlatformTransactionManager.java:579)at org.springframework.transaction.support.AbstractPlatformTransactionManager.rollback(AbstractPlatformTransactionManager.java:556)at org.springframework.transaction.interceptor.TransactionAspectSupport.doCloseTransactionAfterThrowing(TransactionAspectSupport.java:284)at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:100)at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:170)at org.acegisecurity.intercept.method.aopalliance.MethodSecurityInterceptor.invoke(MethodSecurityInterceptor.java:66)at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:170)at org.acegisecurity.intercept.method.aopalliance.MethodSecurityInterceptor.invoke(MethodSecurityInterceptor.java:66)at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:170)at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:176)at $Proxy6.getDataFromDatabase(Unknown Source)at org.myCompany.myAction.load(Unknown Source)at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)at java.lang.reflect.Method.invoke(Method.java:324)at org.apache.struts.actions.DispatchAction.dispatchMethod(DispatchAction.java:274)at org.apache.struts.actions.DispatchAction.execute(DispatchAction.java:194)at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:419)at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:224)at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414)at javax.servlet.http.HttpServlet.service(HttpServlet.java:787)at javax.servlet.http.HttpServlet.service(HttpServlet.java:908)at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264)at org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:107)at org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:72)at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:110)at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125)at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:217)at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:229)at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)at org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148)at org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98)at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:213)at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:280)at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:509)at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:218)at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:509)at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:209)at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:509)at com.iplanet.ias.web.connector.nsapi.NSAPIProcessor.process(NSAPIProcessor.java:157)at com.iplanet.ias.web.WebContainer.service(WebContainer.java:579)
This error occurs on a production environment so I don't know which query produced the problem, but I do know that none of my tables has a column named '123'. Do you have any suggestions about what might be causing this problem?
Edit: As a followup, I found that this behavior is a known bug in MySQL 5.0.4, but I haven't found a good wokaround since I don't have the option of upgrading mySQL.
Could be that somehow the character set for the field has been set to an invalid value, run this SQL on the server with the problem replacing the table name and the column 'Collation' will show the characterset for each varchar/char fields
SHOW FULL COLUMNS IN table_name;
You can then change the character set of a field by using the following:
ALTER TABLE t MODIFY col1 VARCHAR(50) CHARACTER SET latin1;
Internally, MySQL is mapping out the indexes across the columns. Normally this is done using integers that represent the column index. Most indexes are actually a compound index once built (col 1 + col 3) which form something like field 13.
Likely this happened when migrating data from dev into production when the stack is not an exact replica.
As 3urdoch mentioned you can pull the charset using internal MySQL function; and then change the table's charset to a compatible encoding.
Alternatively (where I'm willing to bet this issue came from) you can check if the loaded driver for the Production matches the loaded driver for the Other server. This will prevent re-occurring issue if the Development/Other server is still being used for testing, and migrated into Production.