I have problem with MySQL in PDI (Kettle). This error appears in process of reading information by Input Table. Even if all data is gived out of base successfully, this error appears and, probably, doesn't affect on transformation.
Error comitting connection
Communications link failure during commit(). Transaction resolution unknown.
Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: Communications link failure during commit(). Transaction resolution unknown.
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)...
Why this problem happens?
This is a MySQL error documented in a manual page with a nice title: My sql server has gone away.
Matt Casters (the main author of Kettle) gives a bunch of solutions on the Pentaho wiki which is not yet uploaded on Hitachi Vantara forum.
Matt's first solution is to increase the net_write_timeout. The default is 60 and he did increase it to 1800, mentioning that less may be sufficient.
In order to do this, edit the connection and select Options on the left panel.
Then write net_write_timeout in he Parameters column and 1800 as value.
Related
This is my PHP SQL statement and it's returning false while var dumping
$sql = $dbh->prepare('INSERT INTO users(full_name, e_mail, username, password) VALUES (:fullname, :email, :username, :password)');
$result = $sql->execute(array(
':fullname' => $_GET['fullname'],
':email' => $_GET['email'],
':username' => $_GET['username'],
':password' => $password_hash));
TL;DR
Always have set PDO::ATTR_ERRMODE to PDO::ERRMODE_EXCEPTION in your PDO connection code. It will let the database tell you what the actual problem is, be it with query, server, database or whatever. Also, make sure you can see PHP errors in general.
Always replace every PHP variable in the SQL query with a question mark, and execute the query using prepared statement. It will help to avoid syntax errors of all sorts.
Explanation
Sometimes your PDO code produces an error like Call to a member function execute() or similar. Or even without any error but the query doesn't work all the same. It means that your query failed to execute.
Every time a query fails, MySQL has an error message that explains the reason. Unfortunately, by default such errors are not transferred to PHP, and all you have is a silence or a cryptic error message mentioned above. Hence it is very important to configure PHP and PDO to report you MySQL errors. And once you get the error message, it will be a no-brainer to fix the issue.
In order to get the detailed information about the problem, either put the following line in your code right after connect
$dbh->setAttribute( PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION );
(where $dbh is the name of your PDO instance variable) or - better - add this parameter as a connection option. After that all database errors will be translated into PDO exceptions which, if left alone, would act just as regular PHP errors.
After getting the error message, you have to read and comprehend it. It sounds too obvious, but learners often overlook the meaning of the error message. Yet most of time it explains the problem pretty straightforward:
Say, if it says that a particular table doesn't exist, you have to check spelling, typos, letter case. Also you have to make sure that your PHP script connects to a correct database
Or, if it says there is an error in the SQL syntax, then you have to examine your SQL. And the problem spot is right before the query part cited in the error message.
You have to also trust the error message. If it says that number of tokens doesn't match the number of bound variables then it is so. Same goes for absent tables or columns. Given the choice, whether it's your own mistake or the error message is wrong, always stick to the former. Again it sounds condescending, but hundreds of questions on this very site prove this advice extremely useful.
Note that in order to see PDO errors, you have to be able to see PHP errors in general. To do so, you have to configure PHP depends on the site environment:
on a development server it is very handy to have errors right on the screen, for which displaying errors have to be turned on:
error_reporting(E_ALL);
ini_set('display_errors',1);
while on a live site, all errors have to be logged, but never shown to the client. For this, configure PHP this way:
error_reporting(E_ALL);
ini_set('display_errors', 0);
ini_set('log_errors', 1);
Note that error_reporting should be set to E_ALL all the time.
Also note that despite the common delusion, no try-catch have to be used for the error reporting. PHP will report you PDO errors already, and in a way better form. An uncaught exception is very good for development, yet if you want to show a customized error page, still don't use try catch for this, but just set a custom error handler. In a nutshell, you don't have to treat PDO errors as something special but regard them as any other error in your code.
P.S.
Sometimes there is no error but no results either. Then it means, there is no data to match your criteria. So you have to admit this fact, even if you can swear the data and the criteria are all right. They are not. You have to check them again. I've short answer that would help you to pinpoint the matching issue, Having issue with matching rows in the database using PDO. Just follow this instruction, and the linked tutorial step by step and either have your problem solved or have an answerable question for Stack Overflow.
Some time ago I had the same problem of not seeing any error messages from mysql. After a research it turned out that the problem has got nothing to do with PHP itself, but with mysql server configuration. The default value of the variable lc_messages_dir pointed to non existing directory. After adding a line in mysqld.cnf, then restarted the mysql server, and finally I was able to see the error messages. For me the following was the right one:
lc_messages_dir=/usr/share/mysql
It is described in the mysql reference manual: https://dev.mysql.com/doc/refman/5.7/en/error-message-language.html
I have an ssis package which uses SQL command to get data from Progress database. Every time I execute the query, it throws this specific error:
ERROR [HY000] [DataDirect][ODBC Progress OpenEdge Wire Protocol driver][OPENEDGE]Internal error -1 (buffer too small for generated record) in SQL from subsystem RECORD SERVICES function recPutLONG called from sts_srtt_t:::add_row on (ttbl# 4, len/maxlen/reqlen = 33/32/33) for . Save log for Progress technical support.
I am running the following query:
Select max(ROWID) as maxRowID from TableA
GROUP BY ColumnA,ColumnB,ColumnC,ColumnD
I've had the same error.
After change startup-parameter -SQLTempStorePageSize and -SQLTempStoreBuff to 24 and 3000 respectively the problem was solved.
I think, for you the values must be changed to 40 and 20000.
You can find more information here. The name of the parameter in that article was a bit different than in my Database, it depends on the Progress-version witch is used.
I recently developed a Java client which allow me to query my Hive tables from a simple url .
Unfortunately , since last Thursday the queries seems to have some issues . From time to time , my query which worked before , doesn't return me anything .
So I decided to take a look at my logs, and everytime I do a query this occur :
java.sql.SQLException: Query returned non-zero code: 12, cause: FAILED: Hive Internal Error: java.lang.RuntimeExcep
tion(org.apache.hadoop.ipc.RemoteException: org.apache.hadoop.hdfs.server.namenode.SafeModeException: Cannot create
directory /tmp/hive-root/hive_2015-06-29_09-19-53_268_7855618362212093455. Name node is in safe mode.
Resources are low on NN. Safe mode must be turned off manually.
I think the issue come from the node itself , because I didn't do any changes on my code or in my hive tables . What do you think the problem come from ? And what can I do to resolve it ?
Thank you for your reading my question .
This was due the cluster automatically entered in safe mode. We fixed it by freeing/adding some disk space.
I am trying to connect XPagesJDBC.nsf to a simple MS Access database,
it connects Successfully and i am able to perform the #JdbcInsert , Update, Delete. also able to execute SQL Query operations.
But i am facing an issue while trying to showing data in ViewPanel control with JDBC Query datasource type.
It give bellow error
Error while reading the relational data
Invalid Fetch Size
and a long StackTrace, i am copying some part of stack trace bellow;
I think this error is specific to MS Access, because i could find some successful implementation with other RDBMS also it work fine with "durby" at my end.
com.ibm.xsp.util.FacesUtil.renderComponent(FacesUtil.java:840)
com.ibm.xsp.util.FacesUtil.renderComponent(FacesUtil.java:851)
com.ibm.xsp.util.FacesUtil.renderComponent(FacesUtil.java:851)
com.ibm.xsp.util.FacesUtil.renderComponent(FacesUtil.java:851)
com.ibm.xsp.util.FacesUtil.renderComponent(FacesUtil.java:851)
com.ibm.xsp.component.UIViewRootEx._renderView(UIViewRootEx.java:1317)
com.ibm.xsp.component.UIViewRootEx.renderView(UIViewRootEx.java:1255)
com.ibm.xsp.application.ViewHandlerExImpl.doRender(ViewHandlerExImpl.java:641)
com.ibm.xsp.application.ViewHandlerExImpl._renderView(ViewHandlerExImpl.java:320)
com.ibm.xsp.application.ViewHandlerExImpl.renderView(ViewHandlerExImpl.java:335)
com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:103)
com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:210)
com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:120)
com.ibm.xsp.controller.FacesControllerImpl.render(FacesControllerImpl.java:264)
com.ibm.xsp.webapp.FacesServlet.serviceView(FacesServlet.java:248)
com.ibm.xsp.webapp.FacesServletEx.serviceView(FacesServletEx.java:200)
com.ibm.xsp.webapp.FacesServlet.service(FacesServlet.java:160)
com.ibm.xsp.webapp.FacesServletEx.service(FacesServletEx.java:137)
com.ibm.xsp.webapp.DesignerFacesServlet.service(DesignerFacesServlet.java:103)
com.ibm.designer.runtime.domino.adapter.ComponentModule.invokeServlet(ComponentModule.java:576)
com.ibm.domino.xsp.module.nsf.NSFComponentModule.invokeServlet(NSFComponentModule.java:1267)
com.ibm.designer.runtime.domino.adapter.ComponentModule$AdapterInvoker.invokeServlet(ComponentModule.java:847)
com.ibm.designer.runtime.domino.adapter.ComponentModule$ServletInvoker.doService(ComponentModule.java:796)
com.ibm.designer.runtime.domino.adapter.ComponentModule.doService(ComponentModule.java:565)
com.ibm.domino.xsp.module.nsf.NSFComponentModule.doService(NSFComponentModule.java:1251)
com.ibm.domino.xsp.module.nsf.NSFService.doServiceInternal(NSFService.java:598)
com.ibm.domino.xsp.module.nsf.NSFService.doService(NSFService.java:421)
com.ibm.designer.runtime.domino.adapter.LCDEnvironment.doService(LCDEnvironment.java:341)
com.ibm.designer.runtime.domino.adapter.LCDEnvironment.service(LCDEnvironment.java:297)
com.ibm.domino.xsp.bridge.http.engine.XspCmdManager.service(XspCmdManager.java:272)
java.sql.SQLException: Invalid Fetch Size
sun.jdbc.odbc.JdbcOdbcStatement.setFetchSize(JdbcOdbcStatement.java:838)
sun.jdbc.odbc.JdbcOdbcResultSet.setFetchSize(JdbcOdbcResultSet.java:2987)
com.ibm.xsp.extlib.jdbc.model.JdbcDataBlockAccessor.loadBlock(JdbcDataBlockAccessor.java:389)
com.ibm.xsp.extlib.model.DataBlockAccessor.findBlockByIndex(DataBlockAccessor.java:344)
com.ibm.xsp.extlib.model.DataBlockAccessor.prefetchData(DataBlockAccessor.java:292)
com.ibm.xsp.extlib.model.DataAccessorModel.getRowCount(DataAccessorModel.java:93)
com.ibm.xsp.component.UIPager$PagerState.<init>(UIPager.java:76)
com.ibm.xsp.component.UIPager$PagerState.<init>(UIPager.java:71)
com.ibm.xsp.component.UIPager.createPagerState(UIPager.java:540)
com.ibm.xsp.renderkit.html_extended.XPagerRenderer.encodeChildren(XPagerRenderer.java:67)
com.ibm.xsp.renderkit.ReadOnlyAdapterRenderer.encodeChildren(ReadOnlyAdapterRenderer.java:162)
javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:979)
com.ibm.xsp.util.FacesUtil.renderComponent(FacesUtil.java:842)
com.ibm.xsp.renderkit.html_extended.ViewPanelRenderer.processPagerCell(ViewPanelRenderer.java:656)
com.ibm.xsp.renderkit.html_extended.ViewPanelRenderer.encodeBegin(ViewPanelRenderer.java:354)
com.ibm.xsp.renderkit.ReadOnlyAdapterRenderer.encodeBegin(ReadOnlyAdapterRenderer.java:146)
javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:956)
javax.faces.component.UIData.encodeBegin(UIData.java:788)
com.ibm.xsp.component.UIDataEx.encodeBegin(UIDataEx.java:413)
com.ibm.xsp.component.UIViewPanel.encodeBegin(UIViewPanel.java:288)
com.ibm.xsp.util.FacesUtil.renderComponent(FacesUtil.java:840)
com.ibm.xsp.util.FacesUtil.renderComponent(FacesUtil.java:851)
com.ibm.xsp.util.FacesUtil.renderComponent(FacesUtil.java:851)
myconnection.jdbc file ; ext_db is a DSN
<jdbc>
<driver>sun.jdbc.odbc.JdbcOdbcDriver</driver>
<url>jdbc:odbc:ext_db</url>
<user>xxx</user>
<password>xxx</password>
</jdbc>
The tongue-in-cheek-answer: get a database :-)
The problem seems to be well known and plagues others too to quite some extend. The batch-size parameter (first link) might work. You also could revisit your requirements. Would DECS do the trick?
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.