LOAD DATA LOCAL INFILE only works sometimes - mysql

I have a LOAD DATA command that works fine in the MySQL terminal. It works fine in a test PHP file served from my local server. It works fine in phpMyAdmin on the same server. It inexplicably breaks down when run from Magento, also on the same server.
I have confirmed all methods are using the same login credentials. If I copy the failed command (including all previous queries from connection onwards) from the query log and paste into any other method it mysteriously works again. The query itself cannot be at fault.
Therefore I deduce the problem must be a permissions one. File privilege is set and works for other implementations on the same account. Magento is using pdo_mysql as it's connection. If I duplicate that in a test file it works. Magento must be setting some parameter that is interfering.
The error I get is SQLSTATE[42000]: Syntax error or access violation: 1148 The used command is not allowed with this MySQL version. I must use the "LOCAL" modifier keyword because I cannot guarantee the database server will be accessible.
The nearest previous question here on SO concerns drupal, the error is different but I recall drupal also uses pdo_mysql to connect, perhaps it is related. The only other mention of this error on Magento is this thread which also fails on a LOAD DATA LOCAL INFILE command.

Per #DeveloperChris' suggestion, you can enable SQL logging in Magento in the Varien_Db_Adapter_Pdo_Mysql class (in the lib\Varien path). Change the $_debug and $_logAllQueries class variables to true. You can also change the file path where the queries are logged in $_debugFile.
Don't forget to turn it off before production!
HTH,
JD

Related

MariaDB node.js script throws ER_LOCAL_INFILE_WRONG_FILENAME error when trying to load data into table from local XML file

I have a node.js script which is connecting to a local MariaDB server, creating some tables, and then attempting to load some data into them by executing a SQL query like this:
LOAD XML LOCAL INFILE 'C:\\path\\to\\some_data.xml'
INTO TABLE some_data
ROWS IDENTIFIED BY '<data>';
The script fails with an error like:
SqlError: (conn=60, no: 45034, SQLState: 45034) LOCAL INFILE wrong filename. 'C:\path\to\some_data.xml' doesn't correspond to query LOAD XML LOCAL INFILE 'C:\\path\\to\\some_data.xml'
INTO TABLE some_data
ROWS IDENTIFIED BY '<data>';. Query cancelled. Check for malicious server / proxy
The node.js script code is like:
const pathToXmlFile = path.resolve(__dirname, '../some_data.xml')
.replace(/\\/g, '\\\\');
// .replace(/\\/g, '/');
// none of the above work, and neither does no escaping at all
query = `LOAD XML LOCAL INFILE '${pathToXmlFile}'
INTO TABLE some_data
ROWS IDENTIFIED BY '<data>';`;
I tried escaping the path with forward slashes (I'm running the script through Git Bash), the error remains the same, only the way the path is displayed changes. I have set permitLocalInfile: 'true' on the MariaDB client connection and local_infile=1 on both the [mysqld] and [client] sections of my.ini. The node.js connection user has the FILE privilege.
Node version is 16.13.0, MariaDB npm module version is 2.5.5, all running on the same machine with Windows 10 (MariaDB server too, on localhost).
The above query works perfectly fine when executed from HeidiSQL.
Any ideas on what I'm doing wrong?
I've create a mariadb bug for that : https://jira.mariadb.org/browse/CONJS-181
As a workaround, you might use "/" in place of "\": using "C:/path/to/some_data.xml" won't be escaped avoiding this bug
It seems that it's a bug with the mariadb node connector, I have opened an issue here:
https://github.com/mariadb-corporation/mariadb-connector-nodejs/issues/183
In the meantime, I have tried the mysql2 and mysql connectors, the first doesn't seem to support the permitLocalInfile: 'true' connection option, so I switch to the standard mysql connector and everything works fine (with a few changes in the code because of slight differences in method calling).
If the bug in the mariadb connector is fixed, I will update the answer here.

MySQL: How to enable load data local on both, client and server sides

I tried to upload a .txt file into MySQL Workbench, but I have the following issue:
Error Code: 3948 Loading Local data is disable; this must be enable on both the client and server sides
Workbench uses a MySQL feature called LOAD DATA LOCAL for this .txt file import operation. Because that feature exposes some security problems in the server, the operator of the server needs to enable that feature, by running the MySQL server software (mysqld, it's called) with a specific system variable called local_infile. Your error message means that flag is not enabled.
You can try enabling it at runtime before you do your upload operation. Try this SQL statement.
SET ##GLOBAL.local_infile = 1;
If that doesn't work you need to ask the person who runs your server to enable it.

Difference In Phpmyadmin Mysql web client and Terminal client

I got problem (#2006 Mysql server gone away) with mysql while connecting and performing some operations through web browser.
Operation Listed below:
When Executing big procedure
Importing database dump
When Access some particular tables It immediately throws "Server gone away".
Refer this question for Scenarios: Record Not Inserted - #2006 Mysql server gone away
Note : The above operations are works fine when I perform through terminal.
I tried some configuration as googing stated. That is set wait_timeout, max_allowed_packet. I checked for the bin_log but it is not available.
But the issues will not rectified.
What is the problem & How can I figure out & fix the issue?
what is the different between access phpmyadmin mysql server from web browser and terminal?
Where I can find the mysql server log file?
Note: If you know about any one of the above questions. Please post here. It would be helpful to trace.
Please help me to figure this out..
Thanks in advance...
Basically nothing except phpMyAdmin is limited by PHP's timeout and resource limits (limits to keep a runaway script from bogging down your entire machine for all eternity; see the docs for details of those values. In some cases, you might be authenticating through a different user account (for instance, root#localhost and root#127.0.0.1 aren't the same user), but as long as you're using a user with the same permissions the differences are minimal.
You can read more about logs in the MySQL manual, note that "By default, no logs are enabled (except the error log on Windows)".
Below are answer for question
From my research the problem is that browser have some limit to disconnect the connection i.e timeout connection. So that the above problem raised.
To resolve this problem
Go to /opt/lampp/phpmyadmin and open config.inc.php
add the command $cfg['ExecTimeLimit'] = 0;
Restart the xamp server. Now you can perform any operations.
`
2. Web client is differ from terminal because Terminal client will not getting timeout. Terminal client maintain the connection till the progress completed. I recommenced to use command prompt to import/export/run process by safe way.
Basically phpmyadmin will not have any log file. If you wanna see warnings and error you should configure the log file.
Configuration steps:
Go to /opt/lampp/etc/my.cnf
Add log_bin = /opt/lampp/var/mysql/filename.log
Restart the xamp server. You can get the log information.

Cakephp is not establishing a database link

I have a cake installation on a webserver and a database on a separate server.
I am able to connect to the database remotely via shell, but my cake gives
Error: Mysql requires a database connection
Error: Confirm you have created the file : app/Config/database.php.
Notice: If you want to customize this error message, create app/View/Errors/missing_connection.ctp.
I checked and PDO is setup, mod_rewrite is enabled and I have a similar setup on development server running properly. I checked core.php and it echoes proper base site url, and database.php echoes proper database selection.
Any ideas what may be causing it?
Trying to cover all of the possibilities...
With regard to the database.php file, make sure that the database credentials are being set to the $default variable and not $test, unless of course you're trying to run database unit tests of course.
The file that handles all of the initializing is the webroot's index.php file. You'll want to verify that all paths within that file are using the proper paths. If all you did was extract the CakePHP framework without any folder rearrangements, it should be all correct.
You mention that you checked mod_rewrite is enabled - did you do this with a phpinfo() call to a file located on the same (sub)domain just to verify the settings in the same location?
Although not related to the errors you're experiencing, you'll also want to verify that the external DB allows connection from your webserver's IP.

MySQL can't write to file, permission denied. (Error 13)

I have a web application that runs queries on the database. The application is trying to run a query, and send the results to the an output file. I have confirmed that the issue is actually a permission denied (error 13) problem, not an issue with any other part of the query. A simplified form of the query follows:
SELECT 'anything'
INTO OUTFILE '/var/www/html/sl/filestore/dbadpt_database.tmp'
FROM INFORMATION_SCHEMA.TABLES;
This query runs fine when I remove the INTO OUTFILE line. I have tried every permissions setting for this dir that I can think of. I have even changed the permission to 777, and gotten the same results. (Yes, I know 777 is not secure. Just did it for testing) I have tried every ownership combination of 'root', 'apache', and 'mysql' that I could think to try for this dir. I have pasted the above query into the MySQL command-line tool, and it has produced the same results.
We are running CentOS 5.5. The web server running the application is Apache 2. I cannot create the file ahead of time, nor can I change the directory that the program is trying to write to.
I would hazard a guess that problem is with SELinux.
The first thing I would try would be setenforce 0 and see if that fixed it. It will only fix the symptoms (you still need to reconfigure SELinux to allow what you need), but it will at least confirm whether that's the problem or not.