PHPMyAdmin is showing some strange results when I go to export a table as SQL. If I go to the main database and select Export (i.e. the whole database) at the top it works as expected but when I go to a table and try end export just that table, there is no SQL option in the select list on the "Format:" section.
I am using Server version: 5.5.62(MySQL) and phpmyadmin 4.8.4. This is server wide (happening on all db's on this server)
There is a workaround, I can go to the main database level and export all and only tick the options of the tables I want but want to get this to work.
I have read about a max_input_vars setting but if this was the case, it would not export the whole DB, this just happens at a table level.
Thanks in advance
The fix does work, have applied it to many servers at this point.
Fix # 14775 : edit 'Export.php'
Resolution:
Connect to the server via SSH.
Open file:
/usr/local/psa/admin/htdocs/domains/databases/phpMyAdmin/libraries/classes/Display/Export.php with a text editor.
Note: for Windows, it will be
%plesk_dir%admin\htdocs\domains\databases\phpMyAdmin\libraries\classes\Display\Export.php.
Find line /* Scan for plugins */
Add the following above the line:
// Export a single table
if (isset($_GET['single_table'])) {
$GLOBALS['single_table'] = $_GET['single_table'];
}
This is caused by a bug in version 4.8.4 of phpmyadmin. ppmyadmin team are working on it in this github issue.
There seems to a workaround available (I did not test it myself) : if I select the db, then checkbox the table(s), exporting under "with selected" I get the SQL option.
I am using xampp in ubuntu locally and I don't have /usr/local/psa/admin/htdocs/domains/databases/phpMyAdmin/libraries/classes/Display/Export.php file. SO I searched about this file and I found it here: /opt/lampp/phpmyadmin/libraries/classes/Display/Export.php
After editing this file from the
// Export a single table
if (isset($_GET['single_table'])) {
$GLOBALS['single_table'] = $_GET['single_table'];
}
(as the first answer) resolved my problem.
Related
There's something I've done a hundred times: exporting a mysql database from one server and importing it into another. The export function provides an .sql file which then gets imported to the new server. However, my servers recently updated their phpMyAdmin version (currently 4.6.0) and now whenever I try to do that I get an error when trying to import. I think that has something to do with the escaping as one of the lines now looks like that in the exported file:
(5, 'that\\\'s not even', '2014-05-25 22:35:51', 0)
That is a part of INSERT statement for one of the tables and the triple \\\ is what bothers me. I've tried to look around the configuration and find something related to the escaping but alas no luck. No sure if that's the issue really but any tip on what might be wrong and how to fix it is more than welcome.
EDIT:
In face, that line seems to have nothing in common with the error. The error that gets displayed on import is the following:
Static analysis:
1 errors were found during analysis.
Ending quote ' was expected. (near "" at position 2615077)
After that a very long query follows and I also don't know if that's relevant or not but it ends with this following line which is far from being last:
(33, 'active_plugins', 'a:2:{i:0;s:37:"admin-in-english/admin-in-english.php";i:1;s:29:"filedownload/filedownload.php";}', 'yes'),
That last one in particular is from a bunch of WordPress tables in the database if that matters.
EDIT2:
And here's something even more interesting. I keep backups of old database dumps so I tried to import a dump from a couple of months back that definitely imported successfully back then. Right now, same file, but error once I try to do the import...
After a lot of headbanging it turns out that the problem was limitations imposed by PHP for files larger than 6MB. After 6MB of query it would just cut it right there and logically throw and error afterwards.
The solution is either to change them or in my case, as I don't have direct access to the configuration files: SSH import worked successfully.
I'm working on PhpStorm to develop my Prestashop websites and I can't resolve this issue. I work on localhost and successfully connected PhpStorm to my MySQL Server.
Now PhpStorm throws warnings like "unable to resolve table '${_DB_PREFIX_}cms'". Prestashop uses prefixes for table names and it seems PhpStorm can't resolve those tables with prefixes.
Is there a workaround for this ?
Here is a code exemple from Prestashop-1.6 sources :
$sql = 'SELECT c.`id_cms`, cl.`meta_title`, cl.`link_rewrite`
FROM `'._DB_PREFIX_.'cms` c
INNER JOIN `'._DB_PREFIX_.'cms_shop` cs
ON (c.`id_cms` = cs.`id_cms`)
INNER JOIN `'._DB_PREFIX_.'cms_lang` cl
ON (c.`id_cms` = cl.`id_cms`)
WHERE c.`id_cms_category` = '.(int)$id_cms_category.'
AND cs.`id_shop` = '.(int)$id_shop.'
AND cl.`id_lang` = '.(int)$id_lang.
$where_shop.'
AND c.`active` = 1
ORDER BY `position`';
The reason why this isn't work is because you are most likely only loading one schema, you need to load the information_schema.*
To do this, go to the database tab in the top right and where you have added your MySQL database right click and select properties.
Now you'll have a screen called Data Sources and Drivers, it should open on a tab called General, click the third tab called Schemas and and add information_schema.* to this list of loaded Schemas.
Click apply and okay and then PhpStorm will now know your database structure and then be intelligently able to work with you, therefor removing all the errors.
Edit: As mentioned here, this has been fixed in PhpStorm 2018.2, but only for constants.
I have a solution that doesn't involve throwing your IDE away. :)
However, a word of caution: it's an ugly hack™ that comes without guarantees.
Assuming you already have a connection to the db in PhpStorm, generate the ddl for the desired db (Right Click on the connection -> SQL Scripts -> Generate DDL to Clipboard):
Paste the content into some sql file somewhere inside your project. You should probably gitignore this file.
Replace all the tables' prefix in this ddl file with the one from your code. Use the PhpStorm typehint as a guideline. For example '._DB_PREFIX_.'cms would become ${_DB_PREFIX_}cms:
Note that you may have to use backticks to avoid breaking sql syntax due to curly brackets.
Add the ddl to your phpstorm project:
Everything should now work:
Add this comment above the $sql query.
/** #noinspection SqlResolve */
This will suppress the warning only for this statement.
For future readers, this is now supported:
https://www.jetbrains.com/help/phpstorm/2021.1/ide-advanced-metadata.html#set-up-dynamic-prefixes-for-table-names-in-sql-language-injections
.phpstorm.meta.php
<?php
namespace PHPSTORM_META {
override(
// Virtual function to indicate that all SQL
// injections will have the following replacement rules.
sql_injection_subst(),
map([
'{' => "", // all `{` in injected SQL strings will be replaced with a prefix
'}' => '', // all `}` will be replaced with an empty string
]));
}
Edit: At time of writing (2016) there was no solution to this issue. But since 2018, as mentioned in Christian's answer, you can now use constants in SQL queries.
Actually there is no way to handle that. But you may disable inspection for such warning.
Open File > Settings > Editor > Inspections
Expand SQL
Uncheck Unresolved reference
I have a MySQL database from which I am trying to export data using
SELECT...INTO OUTFILE...FROM
into the My Documents folder on Windows. I would like the code to work in any computer and I am stuck on how to write the file path.
I tried
SELECT...INTO OUTFILE 'C:/Users/%username%/Documents/filename.txt'...
and I failed. I looked for a solution in the Internet without finding one.
Can someone help me please! Thanks in advance.
It depends on what context it is running in. It is not going to appear on a user box (unless the user box is the server). On a server, without a path, it gets plopped in the dir represented by the value seen thru
show variables where variable_name ='datadir';
Then, under that dir, in the dir that represents the database dir. So for me right now that would be
C:\ProgramData\MySQL\MySQL Server 5.6\data\so_gibberish
as so_gibberish is my db name.
If, on my server, I wanted it to go to my dev dir off the root, it would be either
select * from t1 into outfile 'c:\\dev\\t99t.txt';
Note the escape for Windows above.
or
select * from t1 into outfile '/dev/t99t.txt';
Linux.
If the context it is running in is command line, then you have a chance to pick up such things as environment variables.
If the context (a slightly different select stmt, not an into outfile) is PHP/Java (whatever) on a client box pointing to a separate server box, then perhaps prompt them for the dirpath (test you can write there), and proceed. As such that client would get result sets and do fopens and fwrites.
I'm using phpMyAdmin 4.0.2 and seems when doing an export over a whole DB, by default it adds the statement "CREATE DATABASE IF NOT EXISTS" in the beginning of the export SQL.
I wasn't able to find a config option or any option to disable that... So is there a way to disable that and not have that statement in my exports by default?
This behavior did not happen by default in version 3. A quick fix, actually a hack and thus not the desirable solution, is to edit the export class file located in libraries/plugins/export/ExportSql.class.php and force the CREATE and USE statements to be commented out by adding "-- " before them, as such:
Line 709
$create_query = '-- CREATE DATABASE IF NOT EXISTS '
Line 734
'-- USE ' . PMA_Util::backquoteCompat($db, $compat)
Edit: There's a drawback, and that is if you export one or more entire databases (not just some or all the tables inside a database), then the CREATE and USE statements appear commented also.
A better idea as opposed to Hermes's answer would be to edit the file ./export.php ( Mind you: not db_export.php ).
On line 724 ( in phpMyAdmin 4.0.4 ) you'll find the lines:
if (! $export_plugin->exportDBCreate($db)) {
break;
}
You can comment or remove them to skip the creation of the create database statements ( Which in my opinion is also neater then having 2 commented lines in the export ).
Like so:
/*
if (! $export_plugin->exportDBCreate($db)) {
break;
}
*/
The rows above only apply to exporting a single database ( On line 720, you'll find: } elseif ($export_type == 'database') { ). So you won't break full server exports.
What I do is I first select the database on the left sidebar, and then click the Export option. The dump file doesn't contain the CREATE DATABASE statement.
One quick warning, this works for me, but I haven't analyzed if there are any other differences in the SQL export file that you might want to take into consideration
hi there i made track star application and everything works fine except for one issue that i face error
CDbCommand failed to execute the SQL statement: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'devnmark_root.AuthAssignment' doesn't exist. The SQL statement executed was: SELECT *
FROM 'AuthAssignment'
WHERE userid=:userid
now this was automatically generated by Yii when i checked for if(Yii::app()->user->checkAccess('createUser',array('project'=>$model)))
18 {
19 $this->menu[] = array('label'=>'Add User To Project','url'=>array('adduser', 'id'=>$model->id));
20 }
then i went to phpmyadmin and executed this query manually
SELECT * FROMAuthAssignmentWHERE userid=4 and there is error which says same that table does not exist.
if i use small case letter for table name then no error.
i executed same query on local wamp 's phpmyadmin same query does not show any error there so this is clear that there is error with my sql .any idea what can i do to solve?
I suggest you hitting up SQL_MODE documentation for setting your final options. http://dev.mysql.com/doc/refman/5.0/en/server-sql-mode.html
For testing you can just do a:
SET sql_mode = '';
Or adjust your command line:
--sql-mode=""
You may try to set the system variable *lower_case_table_names* to 1.
My local application was developed under Windows, howerver production is under Linux and I caused the same problem.
For me it happened because of case sensitivity - table AuthAssignment in database was actually authassignment.
I have found two options to solve it:
rename database table from authassignment to AuthAssignment
or
edit config file component section:
'components'=>array(
...
'user'=>array(...
),
'authManager'=>array(
...
'assignmentTable'=>'authassignment' //THIS LINE SOLVED MY PROBLEM
),
I had the same problem of non-existent authassignment table, I had forgotten running the rights installation which in my case was by following URL i.e.
/index.php/rights/install
and then the setup was like a breeze and self explanatory :)
For me this answer helped the most: original source.
In the authManager in config/main.php you can add lowercased names of the tables like this:
'components'=>array(
'authManager'=>array(
'defaultRoles'=>array('guest'),
'class'=>'RDbAuthManager',
'assignmentTable'=>'authassignment',
'itemTable'=>'authitem',
'rightsTable'=>'rights',
'itemChildTable'=>'authitemchild',
),