I am getting this error in my phpmyadmin after recently installing new local xammp server.. Can anybody help on this one?
Warning in .\libraries\dbi\DBIMysqli.class.php#261
mysqli_query(): (HY000/1030): Got error 9 "Bad file descriptor" from storage engine MyISAM
Backtrace
.\libraries\dbi\DBIMysqli.class.php#261: mysqli_query(
object,
string 'SELECT * FROM `mysql`.`db` LIMIT 1',
integer 0,
)
.\libraries\DatabaseInterface.class.php#246: PMA_DBI_Mysqli->realQuery(
string 'SELECT * FROM `mysql`.`db` LIMIT 1',
object,
integer 0,
)
.\libraries\check_user_privileges.lib.php#46: PMA_DatabaseInterface->tryQuery(string 'SELECT * FROM `mysql`.`db` LIMIT 1')
.\libraries\check_user_privileges.lib.php#395: PMA_checkRequiredPrivilgesForAdjust()
.\libraries\List_Database.class.php#17: require_once(.\libraries\check_user_privileges.lib.php)
.\libraries\PMA.php#17: require_once(.\libraries\List_Database.class.php)
.\libraries\common.inc.php#1089: include_once(.\libraries\PMA.php)
.\tbl_structure.php#14: require_once(.\libraries\common.inc.php)
You can run this executable file: mysql_upgrade.exe which is located inside this folder: XAMPP/mysql/bin.. I tried this and it worked.
I also received this recently on a fresh install.
Start MySQL from XAMPP or from the command line
Open command line [Windows] + [r], type "cmd" press [enter]
cd \xampp\mysql\bin
mysql_upgrade.exe
I found this is happening when I do several mysqldump's from MySQL servers and import them over to MariaDB. The update will check all of your mysql databases, fix table privileges, fixes table and database names, upgrades the tables, and flushes.
Old XAMPP packages used MySQL, in XAMPP 5.6.12 it was MySQL 5.6.26.
In the current XAMPP 5.6.14 however, they switched from MySQL to MariaDB 10.0.0.17.
Trying to upgrade the mysql database did not work correctly ("Can't create table..."/"Bad file descriptor"). While mysql_upgrade.exe was running, I had to regularly pause execution. This allowed it to run through.
i tried the solution posted here but it doesn't work (maybe due to Windows and MariaDB). I deciced to do a "quick & dirty" fix.
I navigated to my xampp folder, then /phpmyadmin/libraries/dbi/
Open DBIMysql.class.php - search for
if (! $server)
should be around line 138, insert before the if statement
$user = "your phpmyadmin username";
$password = "your phpmyadmin password";
Save the file and use the control to restart MySQL (alias MariaDB). Basically it just overwrites the variables user and password - it seems that the new MariaDB has a problem to receive the password and username in that class. After I did that, no more errors have occured.
But as I mentioned: be careful because this is a very dirty fix ;)
Hope it helps :)
The solution of this run as adminstrator mysql_upgrade.exe which is located inside this folder: XAMPP/mysql/bin.. I tried this and it work.
Deepesh Tripathi
vWarning in .\libraries\classes\Dbal\DbiMysqli.php#209
mysqli::query(): (HY000/1034): Index for table 'global_priv' is corrupt; try to repair it
Backtrace
DbiMysqli.php#209: mysqli->query(
string 'SELECT 1 FROM mysql.user LIMIT 1',
integer 0,
)
DatabaseInterface.php#219: PhpMyAdmin\Dbal\DbiMysqli->realQuery(
string 'SELECT 1 FROM mysql.user LIMIT 1',
,
integer 0,
)
DatabaseInterface.php#1713: PhpMyAdmin\DatabaseInterface->tryQuery(string 'SELECT 1 FROM mysql.user LIMIT 1')
SqlController.php#158: PhpMyAdmin\DatabaseInterface->isSuperUser()
Routing.php#192: PhpMyAdmin\Controllers\Sql\SqlController->__invoke(
,
array,
)
index.php#43: PhpMyAdmin\Routing::callControllerForRoute(
,
string '/sql',
,
,
)
Mình bị lỗi như thế này! Đã fix thành công ( I got this error! Successfully fixed)
Related
I am using 000webhost.com and I am using phpMyAdmin there. I am getting this error from MySQL when I run my PHP script as the title says:
Column count of mysql.proc is wrong. Expected 20, found 16.
The table is probably corrupted.
Is there any solution for this?
<?php
$username="usrname";
$password="passwd";
$database="a1xxxxx_mydb";
$host="mysqlxx.000webhost.com";
mysql_connect($host,$username,$password);
#mysql_select_db($database) or die( "Unable to select database");
if (isset($_GET["userLatitude"]) && isset($_GET["userLongitude"])) {
$userLatitude=$_GET['userLatitude'];
$userLongitude=$_GET['userLongitude'];
$result = mysql_query("SELECT locationName, ( 6371 * acos( cos( radians(floatval( $userLatitude) )) * cos( radians( locationLatitude ) ) * cos( radians( locationLongitude ) - radians( floatval($userLatitude)) ) + sin( radians(floatval($userLongitude)) ) * sin( radians( locationLatitude) ) ) ) AS distance
FROM Location HAVING distance < 2 ORDER BY distance LIMIT 0 ,20") or die(mysql_error());
echo $result;
// check for empty result
if (mysql_num_rows($result) > 0) {
// looping through all results
// products node
$response["Location"] = array();
while ($row = mysql_fetch_array($result)) {
// temp user array
$product = array();
$product["locationName"] = $row["locationName"];
$product["locationInfo"] = $row["locationInfo"];
$product["locationLatitude"] = $row["locationLatitude"];
$product["locationLongitude"] = $row["locationLongitude"];
$product["locationPic"] = $row["locationPic"];
$product["city"] = $row["city"];
// push single product into final response array
array_push($response["Location"], $product);
}
// success
$response["success"] = 1;
// echoing JSON response
echo json_encode($response);
} else {
// no products found
$response["success"] = 0;
$response["message"] = "No products found";
// echo no users JSON
echo json_encode($response);
}
}
else {
// required field is missing
$response["success"] = 0;
$response["message"] = "Required field(s) is missing";
// echoing JSON response
echo json_encode($response);
}
mysql_close();
?>
I had this error as well. I fixed it by running
mysql_upgrade -u root -p
Also, restart the mysql service by running
service mysqld restart
I had the same problem when I updated XAMPP from xampp-osx-7.2.10 to 7.3.9 in MacOS Mohave. So the solution was:
Find the file mysql_upgrade in "Macintosh HD ▸ Applications ▸ XAMPP ▸ xamppfiles ▸ bin" and double click on it.
This error happens when a bad upgrade is done. For example, it happens if you upgrade from 5.0 to 5.1 but don't run the mysql_upgrade script; or, in rare cases, it probably happens if you directly upgrade from 5.0 to 5.5. (Many people does this, but such updrages are not officially supported)
You say you are using a hosting service - well, I think that you should create a ticket and tell them about the problem. If you don't have the SUPER privilege, there is nothing you can do.
But if you have that right, simply run mysql_upgrade:
http://dev.mysql.com/doc/refman/5.1/en/mysql-upgrade.html
A similar error appeared in MySQL Workbench 8.0.21 after installing XAMPP 7.4.8 on Ubuntu 18.04. There were no problems using phpMyAdmin.
Error Code: 1558 Column count of mysql.proc is wrong. Expected 21, found 20. Created with MariaDB 100108, now running 100413. Please use mysql_upgrade to fix this error
Solution:
sudo /opt/lampp/lampp start
/opt/lampp/bin/mysql_upgrade
Problem solved
Credits: There appear to be a bug in XAMPP - https://community.apachefriends.org/f/viewtopic.php?f=17&t=78386&sid=3d3824dd0b6aa2e33c3adc73c744b4b4
I had the same problem when I updated the mysql server from 5.5 to 5.7 in Debian 8 (jessie). In my case, it worked fine when I executed the follow command:
mysql_upgrade --force -uroot -p
I am using xampp on Ubuntu 20.04 and the my problem that return this same message error was solved with this solution:
Go to the xampp directory: cd /opt/lampp/
Go to the bin directory: cd bin
Execute the script: sudo ./mysql_upgrade
Credits: https://askubuntu.com/questions/1171409/how-to-run-mysql-upgrade-when-using-xampp
Although you may be correct about the necessity for upgrade, that's not the only reason this error occurs.
When the following is called with a query that returns 1 row
my $rv = $sth_indexq->fetchall_arrayref;
the following error is reported:
DBD::mysql::st execute failed: Column count of mysql.proc is wrong. Expected 20, found 16. Created with MySQL 50520, now running 50528. Please use mysql_upgrade to fix this error. at
...
However, the real cause of the error was use of fetchall_arrayref instead of fetchrow_arrayref. The following worked without errors:
my $rv = $sth_indexq->fetchrow_arrayref;
The data in $rv was only 1 level deep, not 2.
The mysql_upgrade solution may very well solve this issue, but the simple solution is know your data and use the right retrieval code.
J.White
I was using a windows 10 system and the solution that worked for me was
mysql_upgrade -u root -p
But you need to ensure that the path to the mysql_upgrade script which is present in the mysql/bin folder of your installation directory needs to be added in the environment variable path for this command to work
Hit on browser below command
/opt/lampp/bin/mysql_upgrade
For Linux
If you are using LAMPP, then you can fix it like -
sudo /opt/lampp/lampp start
/opt/lampp/bin/mysql_upgrade
else if you installed mysql separately, then you can like this -
mysql_upgrade -u root -p
service mysqld restart
For any other OS, you can simply go to bin directory of lampp installation & try to find mysql_upgrade file & execute it.
This my happen when eg. upgrading instead of migrating;
The part where it reads version check failed is the relevant part:
Version check failed. Got the following error when calling the 'mysql' command line client
ERROR 1045 (28000): Access denied for user 'root'#'localhost' (using password: YES)
FATAL ERROR: Upgrade failed
Obviously this is about an incompatible client version, but the mysql database is also different.
This here would be the current definition of the mysql.proc table ... which shows that enum column type has changed and that column aggregate has been added, since MariaDB 10.3.3.
Yet another problem is:
In MariaDB 10.4 and later, this table uses the Aria storage engine.
Downgrading the server to 5.x and deleting the InnoDB log files, then restoring table proc helped; (for MariaDB 5.x): https://github.com/google/mysql/blob/master/scripts/mysql_system_tables.sql
For me, the problem was caused by prefixing a table alias in front of COUNT() accidentally:
MariaDB> SELECT x.COUNT(1) FROM (SELECT 1) AS x;
ERROR 1558 (HY000): Column count of mysql.proc is wrong. Expected 21, found 20. Created with MariaDB 100137, now running 100334. Please use mysql_upgrade to fix this error
MariaDB> SELECT COUNT(1) FROM (SELECT 1) AS x;
+-------------+
| COUNT(test) |
+-------------+
| 1 |
+-------------+
1 row in set (0.001 sec)
As you see, without the prefix before COUNT() it works. I was adding the table alias to all SELECT fields and, thereby, accidentally also added before the COUNT(). Whether this would give a different error message on a fresh database, I don't know, but the server has been running fine for years and by fixing the query the error goes away so... it seems like a runtime/syntax error to me, not an upgrade/restart problem like for the others in this thread.
can you use it for linux
sudo /opt/lampp/bin/mysql_upgrade
My table looks like
create table try ( name varchar(8), CREATED_BY varchar(40) not null);
and then I have a trigger to auto populate the CREATED_BY field
create trigger autoPopulateAtInsert BEFORE INSERT on try for each row set new.CREATED_BY=user();
When I do an insert using
insert into try (name) values ('abc');
the entry is made in the table but I still get the error message
Field 'CREATED_BY' doesn't have a default value Error no 1364
Is there a way to suppress this error without making the field nullable AND without removing the triggfer? Otherwise my hibernate will see these exceptions ( even though the insertions have been made) and then application will crash.
This is caused by the STRICT_TRANS_TABLES SQL mode defined in the
%PROGRAMDATA%\MySQL\MySQL Server 5.6\my.ini
file. Removing that setting and restarting MySQL should fix the problem.
See https://www.farbeyondcode.com/Solution-for-MariaDB-Field--xxx--doesn-t-have-a-default-value-5-2720.html
If editing that file doesn't fix the issue, see http://dev.mysql.com/doc/refman/5.6/en/option-files.html for other possible locations of config files.
Open phpmyadmin and goto 'More' Tab and select 'Variables' submenu.
Scroll down to find sql mode.
Edit sql mode and remove 'STRICT_TRANS_TABLES'
Save it.
In phpmyadmin, perform the following:
select ##GLOBAL.sql_mode
In my case, I get the following:
ONLY_FULL_GROUP_BY, STRICT_TRANS_TABLES ,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
Copy this result and remove STRICT_TRANS_TABLES. Then perform the following:
set GLOBAL sql_mode='ONLY_FULL_GROUP_BY,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION'
Set a default value for Created_By (eg: empty VARCHAR) and the trigger will update the value anyways.
create table try (
name varchar(8),
CREATED_BY varchar(40) DEFAULT '' not null
);
When I had this same problem with mysql5.6.20 installed with Homebrew, I solved it by going into my.cnf
nano /usr/local/Cellar/mysql/5.6.20_1/my.cnf
Find the line that looks like so:
sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES
Comment above line out and restart mysql server
mysql.server restart
Error gone!
Run mysql console:
mysql -u your_username -p
, select database:
USE your_database;
and run (also from mysql console):
SET GLOBAL sql_mode='';
That will turn off strict mode and mysql won't complain any more.
To make things clear: your database definition says "this field must have default value defined", and by doing steps from above you say to MySql "neah, just ignore it". So if you just want to do some quick fix locally this solution is ok. But generally you should investigate in your database definition and check if field really needs default value and if so set it. And if default value is not needed this requirement should be removed to have clean situation.
As others said, this is caused by the STRICT_TRANS_TABLES SQL mode.
To check whether STRICT_TRANS_TABLES mode is enabled:
SHOW VARIABLES LIKE 'sql_mode';
To disable strict mode:
SET GLOBAL sql_mode='';
Before every insert action I added below line and solved my issue,
SET SQL_MODE = '';
I'm not sure if this is the best solution,
SET SQL_MODE = ''; INSERT INTO `mytable` ( `field1` , `field2`) VALUES ('value1', 'value2');
Modify your query and add "IGNORE" as:
INSERT IGNORE INTO `mytable` ( `field1` , `field2`) VALUES ('value1', 'value2');
Its work and tested Copy to Config File: /etc/mysql/my.cnf OR /bin/mysql/my.ini
[mysqld]
port = 3306
sql-mode=""
then restart MySQL
This appears to be caused by a long-standing (since 2004) bug (#6295) in MySQL, titled
Triggers are not processed for NOT NULL columns.
It was allegedly fixed in version 5.7.1 of MySQL (Changelog, last entry) in 2013, making MySQL behave as “per the SQL standard” (ibid).
For Windows WampServer users:
WAMP > MySQL > my.ini
search file for sql-mode=""
Uncomment it.
In Windows Server edit my.ini (for example program files\mysql\mysql server n.n\my.ini)
I would not simply set the sql-mode="", rather I suggest one removes STRICT_TRANS_TABLES from the line, leave everything as-was, and then restart MySQL from the services utility. Add a comment for future programmers who you are and what you did.
Most of these answers are a lot of work for the not-seasoned coder. Like mentioned the issues is with STRICT_TRANS_TABLES.
First verify STRICT_TRANS_TABLES is running.
$ mysql -u root -p -e "SHOW VARIABLES LIKE 'sql_mode';"
You can disable strict mode on your MySQL server by running the following command on your Linode's command line:
$ mysql -u root -p -e "SET GLOBAL sql_mode = 'NO_ENGINE_SUBSTITUTION';"
Then, you can verify that the mode is set by running the following:
$ mysql -u root -p -e "SELECT ##GLOBAL.sql_mode;"
This answer was found here https://www.linode.com/community/questions/17070/how-can-i-disable-mysql-strict-mode
i set the fields to not null and problem solved, it updates when an information is commanded to store in it, no more showing msqli message that the field was empty cus you didnt insert value to it, well application of this solution can work on some projects depends on your project structure.
This is for SYNOLOGY device users:
How to set global variables (strict mode OFF) on SYNOLOGY device.
(checked on DSM 7.0.1-42218 - device model DS418)
Used PUTTY to connect:
login as root and
sudo su after... (to be admin total)
if not exist create my.cnf in:
MariaDB 5:
/var/packages/MariaDB/etc
MariaDB 10:
/var/packages/MariaDB10/etc
this should be in the file (at least for strict mode off)
# custom configs
[mysqld]
innodb_strict_mode = OFF
sql_mode = ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
restart mysqld daemon:
MariaDB 5:
/usr/syno/bin/synopkg restart MariaDB
MariaDB 10:
/usr/syno/bin/synopkg restart MariaDB10
check for strict mode enabled at these two global options - both should be not there or off (see config above)
log into mysql:
mysql -u root -p
enter password:
show variables like 'sql_mode';
show variables like '%STRICT%';
i solved problem changing my.ini file located in data folder. for mysql 5.6 my.ini file moved to data folder rather the bin or mysql installation folder.
I think in name column have null values in this case.
update try set name='abc' where created_by='def';
I am using Xampp 7.3.28-1 for Linux. It uses MariaDB 10.4.19. Its configuration file is:
/opt/lampp/etc/my.cnf
It does NOT contain an entry that defines sql_mode.
However the query "select ##GLOBAL.sql_mode;" does return a result and it contains the problematic STRICT_TRANS_TABLES. I guess it is by default now.
My solution was to explicitly define the mode by adding this line below [mysqld]:
sql_mode=NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
You can define the modes that you need or just leave it blank.
I found that once I removed what was a doubling up of a foreign key and primary key, when I could have just used the foreign key as the primary key alone in the table. All my code then worked and I was able to upload to db.
I am using 000webhost.com and I am using phpMyAdmin there. I am getting this error from MySQL when I run my PHP script as the title says:
Column count of mysql.proc is wrong. Expected 20, found 16.
The table is probably corrupted.
Is there any solution for this?
<?php
$username="usrname";
$password="passwd";
$database="a1xxxxx_mydb";
$host="mysqlxx.000webhost.com";
mysql_connect($host,$username,$password);
#mysql_select_db($database) or die( "Unable to select database");
if (isset($_GET["userLatitude"]) && isset($_GET["userLongitude"])) {
$userLatitude=$_GET['userLatitude'];
$userLongitude=$_GET['userLongitude'];
$result = mysql_query("SELECT locationName, ( 6371 * acos( cos( radians(floatval( $userLatitude) )) * cos( radians( locationLatitude ) ) * cos( radians( locationLongitude ) - radians( floatval($userLatitude)) ) + sin( radians(floatval($userLongitude)) ) * sin( radians( locationLatitude) ) ) ) AS distance
FROM Location HAVING distance < 2 ORDER BY distance LIMIT 0 ,20") or die(mysql_error());
echo $result;
// check for empty result
if (mysql_num_rows($result) > 0) {
// looping through all results
// products node
$response["Location"] = array();
while ($row = mysql_fetch_array($result)) {
// temp user array
$product = array();
$product["locationName"] = $row["locationName"];
$product["locationInfo"] = $row["locationInfo"];
$product["locationLatitude"] = $row["locationLatitude"];
$product["locationLongitude"] = $row["locationLongitude"];
$product["locationPic"] = $row["locationPic"];
$product["city"] = $row["city"];
// push single product into final response array
array_push($response["Location"], $product);
}
// success
$response["success"] = 1;
// echoing JSON response
echo json_encode($response);
} else {
// no products found
$response["success"] = 0;
$response["message"] = "No products found";
// echo no users JSON
echo json_encode($response);
}
}
else {
// required field is missing
$response["success"] = 0;
$response["message"] = "Required field(s) is missing";
// echoing JSON response
echo json_encode($response);
}
mysql_close();
?>
I had this error as well. I fixed it by running
mysql_upgrade -u root -p
Also, restart the mysql service by running
service mysqld restart
I had the same problem when I updated XAMPP from xampp-osx-7.2.10 to 7.3.9 in MacOS Mohave. So the solution was:
Find the file mysql_upgrade in "Macintosh HD ▸ Applications ▸ XAMPP ▸ xamppfiles ▸ bin" and double click on it.
This error happens when a bad upgrade is done. For example, it happens if you upgrade from 5.0 to 5.1 but don't run the mysql_upgrade script; or, in rare cases, it probably happens if you directly upgrade from 5.0 to 5.5. (Many people does this, but such updrages are not officially supported)
You say you are using a hosting service - well, I think that you should create a ticket and tell them about the problem. If you don't have the SUPER privilege, there is nothing you can do.
But if you have that right, simply run mysql_upgrade:
http://dev.mysql.com/doc/refman/5.1/en/mysql-upgrade.html
A similar error appeared in MySQL Workbench 8.0.21 after installing XAMPP 7.4.8 on Ubuntu 18.04. There were no problems using phpMyAdmin.
Error Code: 1558 Column count of mysql.proc is wrong. Expected 21, found 20. Created with MariaDB 100108, now running 100413. Please use mysql_upgrade to fix this error
Solution:
sudo /opt/lampp/lampp start
/opt/lampp/bin/mysql_upgrade
Problem solved
Credits: There appear to be a bug in XAMPP - https://community.apachefriends.org/f/viewtopic.php?f=17&t=78386&sid=3d3824dd0b6aa2e33c3adc73c744b4b4
I had the same problem when I updated the mysql server from 5.5 to 5.7 in Debian 8 (jessie). In my case, it worked fine when I executed the follow command:
mysql_upgrade --force -uroot -p
I am using xampp on Ubuntu 20.04 and the my problem that return this same message error was solved with this solution:
Go to the xampp directory: cd /opt/lampp/
Go to the bin directory: cd bin
Execute the script: sudo ./mysql_upgrade
Credits: https://askubuntu.com/questions/1171409/how-to-run-mysql-upgrade-when-using-xampp
Although you may be correct about the necessity for upgrade, that's not the only reason this error occurs.
When the following is called with a query that returns 1 row
my $rv = $sth_indexq->fetchall_arrayref;
the following error is reported:
DBD::mysql::st execute failed: Column count of mysql.proc is wrong. Expected 20, found 16. Created with MySQL 50520, now running 50528. Please use mysql_upgrade to fix this error. at
...
However, the real cause of the error was use of fetchall_arrayref instead of fetchrow_arrayref. The following worked without errors:
my $rv = $sth_indexq->fetchrow_arrayref;
The data in $rv was only 1 level deep, not 2.
The mysql_upgrade solution may very well solve this issue, but the simple solution is know your data and use the right retrieval code.
J.White
I was using a windows 10 system and the solution that worked for me was
mysql_upgrade -u root -p
But you need to ensure that the path to the mysql_upgrade script which is present in the mysql/bin folder of your installation directory needs to be added in the environment variable path for this command to work
Hit on browser below command
/opt/lampp/bin/mysql_upgrade
For Linux
If you are using LAMPP, then you can fix it like -
sudo /opt/lampp/lampp start
/opt/lampp/bin/mysql_upgrade
else if you installed mysql separately, then you can like this -
mysql_upgrade -u root -p
service mysqld restart
For any other OS, you can simply go to bin directory of lampp installation & try to find mysql_upgrade file & execute it.
This my happen when eg. upgrading instead of migrating;
The part where it reads version check failed is the relevant part:
Version check failed. Got the following error when calling the 'mysql' command line client
ERROR 1045 (28000): Access denied for user 'root'#'localhost' (using password: YES)
FATAL ERROR: Upgrade failed
Obviously this is about an incompatible client version, but the mysql database is also different.
This here would be the current definition of the mysql.proc table ... which shows that enum column type has changed and that column aggregate has been added, since MariaDB 10.3.3.
Yet another problem is:
In MariaDB 10.4 and later, this table uses the Aria storage engine.
Downgrading the server to 5.x and deleting the InnoDB log files, then restoring table proc helped; (for MariaDB 5.x): https://github.com/google/mysql/blob/master/scripts/mysql_system_tables.sql
For me, the problem was caused by prefixing a table alias in front of COUNT() accidentally:
MariaDB> SELECT x.COUNT(1) FROM (SELECT 1) AS x;
ERROR 1558 (HY000): Column count of mysql.proc is wrong. Expected 21, found 20. Created with MariaDB 100137, now running 100334. Please use mysql_upgrade to fix this error
MariaDB> SELECT COUNT(1) FROM (SELECT 1) AS x;
+-------------+
| COUNT(test) |
+-------------+
| 1 |
+-------------+
1 row in set (0.001 sec)
As you see, without the prefix before COUNT() it works. I was adding the table alias to all SELECT fields and, thereby, accidentally also added before the COUNT(). Whether this would give a different error message on a fresh database, I don't know, but the server has been running fine for years and by fixing the query the error goes away so... it seems like a runtime/syntax error to me, not an upgrade/restart problem like for the others in this thread.
can you use it for linux
sudo /opt/lampp/bin/mysql_upgrade
I get this error when installing via the web installer, the error says:
DBIx::Class::Storage::DBI::_dbh_execute(): Data truncated for column 'type' at row 1 at /usr/share/koha/lib/Koha/Objects.pm line 101
Installed version is: 16.05.05.000
I installed using packages by following the instructions on this link: https://wiki.koha-community.org/wiki/Koha_on_Debian
The database I'm using is: MySQL database; and it is on the same machine as Koha.
Any idea please!
I was presented with the same error. It appears that the error is given in an enum column in the database. For MySQL you can solve it as follows (inside the MySQL database administrator):
SET GLOBAL sql_mode = '';
When setting the mode with an empty string '' you are telling MySQL not to take into account some errors that arise when inserting data.
MySQL can operate in different modes, some modes are more restrictive than others, for example, some modes do not allow certain operations, such as division by zero or restrict the way in which the dates are represented in the database.
To see how the server is, you must log into MySQL from the command line:
mysql -u root -p
If the MySQL server does not have a password (which is not recommended), omit the -p parameter. You can then check the mode with the following command
SELECT ##GLOBAL.sql_mode;
It will return more or less similar to this:
STRICT_TRANS_TABLES, NO_ENGINE_SUBSTITUTION
You can find more information on this at http://dev.mysql.com/doc/refman/5.7/en/sql-mode.html
Source
install phpmyadmin on different port (say 81)
select koha_library database (where library is the instance)
select ‘search_filed’ table
press ‘structure’ tap
select 'type' column and then press 'change'
change the type to varchar and length to 255 (or you can change the type of column 'type'in table ‘search_filed’ from enum to varchar(255) using the terminal)
execute the following command in server terminal (login using mysql-u root -p ):
SET GLOBAL sql_mode='';
quit;
sudo service mysql restart && sudo service apache2 restart
I have sucessfuly reseted my root password on my localhost xampp. Now when I run the mysql daemon myself ( XAMPP/mysql/bin/mysqld.exe ), I can login with PHPMyAdmin to the MySQL administration with no problem.
However when I run MySQL from XAMPP's Control Panel (the "nice" window with start/stop etc. buttons)
I can't login through PHPMyAdmin anymore - I get error #1045...
This must be something configuration-related? What might be causing this?
Big thanks :)
It seems that mysql daemon in xampp has different default value for the basedir than the my.ini setting file.
So when I've reseted the password without adding the same --defaults-file as XAMPP does when it runs mysqld - I actually reseted a password for a different "workspace".
Thanks to #andy, because his comments led me to the solution :)
So the right way to reset XAMPP's MySQL root user ( on Windows ) is:
1) Stop MySQL with XAMPP Control
2) Prepare init file
Create file called mysql-init.txt directly on C:\ drive and fill it with this content:
#INSERT INTO mysql.user (User,Password) VALUES('root',PASSWORD('root'));
UPDATE mysql.user SET Password=PASSWORD('root') WHERE User='root';
GRANT ALL PRIVILEGES ON * . * TO 'root'#'localhost';
FLUSH PRIVILEGES;
- # is a comment - if you did not have a root user or deleted it by accident - uncomment the first line and comment the second line
These commands create a MySQL user "root" with password "root" and give him/her ALL privileges on everything.
3) Run MySQL daemon with proper params
Run YOUR_XAMPP_INSTALL\mysql\bin\mysqld.exe with these params:
Note the double slashes "\\" instead of single slashes "\"
--defaults-file="c:\\YOUR_XAMPP_INSTALL\\mysql\\bin\\my.ini"
--init-file=C:\\mysql-init.txt
So the whole command for cmd.exe could look like:
c:\YOUR_XAMPP_INSTALL\mysql\bin\mysqld.exe --defaults-file="c:\\YOUR_XAMPP_INSTALL\\mysql\\bin\\my.ini" --init-file=C:\\mysql-init.txt
Of course replace YOUR_XAMPP_INSTALL with the path to your custom xampp install ( very often it is just "xampp" resp. "C:\xampp"). And of course if you are operating on a different drive than "C", change C:\ to WhatEverLetterYouWant:\
4) Try to login on http://localhost/phpmyadmin/
Try to login on http://localhost/phpmyadmin/ with user root and password root, if it does not work, you have done something wrong in the previous 3 steps
5) 4) went fine? => Stop MySQL with XAMPP Control
6) Start MySQL with XAMPP control
7) Try to login again with root/root
8) 7) went fine? => Done :)
References:
http://dev.mysql.com/doc/refman/5.0/en/resetting-permissions.html
https://www.digitalocean.com/community/tutorials/how-to-create-a-new-user-and-grant-permissions-in-mysql