This does not seem to work
mysql> SET PASSWORD FOR juser201411#localhost= PASSWORD(".6,y:C2a");
ERROR 1133 (42000): Can't find any matching row in the user table
After that I tried manually adding from mysql.user
mysql> update mysql.user set password=('.6,y:C2a') where User='juser201411' and Host='localhost';
Query OK, 0 rows affected (0.00 sec)
Rows matched: 0 Changed: 0 Warnings: 0
mysql> flush privileges;
Query OK, 0 rows affected (0.00 sec)
mysql> select User from mysql.user;+------+
| User |
+------+
| root |
| root |
+------+
2 rows in set (0.00 sec)
centos 6.5 x64
Try to use the CREATE USER syntax. For more information see MySQL doc
CREATE USER 'juser201411'#'localhost' IDENTIFIED BY PASSWORD '.6,y:C2a';
For me I had put the line into a txt editor to fill it out and some of my single quotes had gotten converted to smart quotes...hard to see, but obvious once you do(!)
Related
Source: MS Access on Windows network share
Target: MySQL/MariaDB on Ubuntu
Tools: mdb-export, mysqlimport
record count: 1,5 Mio +
I wonder if there is a fast and reliable way of comparing the imported data records.
Is there an SQL standard equivalent to e.g. md5 fingerprint hashes of files? Right now, I am building different import routines and I only want to fast check for similarity and (if failed) search for the detailed differences later on.
A somewhat of a quick-and-dirty approach for individual columns can be implemented using stored aggregate functions which should be SQL standard.
This is how you'd do it with MariaDB:
CREATE AGGREGATE FUNCTION IF NOT EXISTS my_checksum(x TEXT) RETURNS CHAR(40)
DETERMINISTIC
BEGIN
DECLARE cksum CHAR(40) DEFAULT SHA1('');
DECLARE CONTINUE HANDLER FOR NOT FOUND
RETURN cksum;
LOOP
FETCH GROUP NEXT ROW;
SET cksum = SHA1(CONCAT(cksum, x));
END LOOP;
END
You can then calculate a checksum from of a column as such:
MariaDB [test]> create or replace table t1(data varchar(20));
Query OK, 0 rows affected (0.063 sec)
MariaDB [test]> create or replace table t2(data varchar(20));
Query OK, 0 rows affected (0.064 sec)
MariaDB [test]> insert into t1 values ('hello'), ('world'), ('!');
Query OK, 3 rows affected (0.011 sec)
Records: 3 Duplicates: 0 Warnings: 0
MariaDB [test]> insert into t2 values ('Hello'), ('World'), ('!');
Query OK, 3 rows affected (0.015 sec)
Records: 3 Duplicates: 0 Warnings: 0
MariaDB [test]> select my_checksum(data) from t1;
+------------------------------------------+
| my_checksum(data) |
+------------------------------------------+
| 7f6fb9a61c2097f70a36254c332c47364c496e07 |
+------------------------------------------+
1 row in set (0.001 sec)
MariaDB [test]> select my_checksum(data) from t2;
+------------------------------------------+
| my_checksum(data) |
+------------------------------------------+
| 5f683ea3674e33ce24bff5f68f53509566ad4da2 |
+------------------------------------------+
1 row in set (0.001 sec)
MariaDB [test]> delete from t2;
Query OK, 3 rows affected (0.011 sec)
MariaDB [test]> insert into t2 values ('hello'), ('world'), ('!');
Query OK, 3 rows affected (0.012 sec)
Records: 3 Duplicates: 0 Warnings: 0
MariaDB [test]> select my_checksum(data) from t2;
+------------------------------------------+
| my_checksum(data) |
+------------------------------------------+
| 7f6fb9a61c2097f70a36254c332c47364c496e07 |
+------------------------------------------+
1 row in set (0.001 sec)
This of course relies on the SHA1 of the column being the same on all databases. Conversions into strings should make it mostly compatible but there might be differences in how these are implemented in different databases.
The percona toolkit has the tool you need.
https://docs.percona.com/percona-toolkit/
See pt-table-checksum and pt-table-sync
I found it.
It's very simple and very fast.
CHECKSUM TABLE tbl_name
Will give you a number value to compare.
And it's Transact-SQL so will hopefully work the same on MS Access, MySQL and MariaDB
I'm installing MySQL 5.7 on a new Ubuntu 16.04 server. Since my installation uses Ansible, no root password is defined at installation time, and I set it up later with the mysql_user role in ansible, but the root password stays empty.
I therefore tried to run the command directly on MySQL, without Ansible, but I get the same behaviour : no error on the alter user command but password is not set.
My server configuration :
OS :
Distributor ID: Ubuntu
Description: Ubuntu 16.04.1 LTS
Release: 16.04
Codename: xenial
Database : MySQL 5.7.12-0ubuntu1.1
Step to reproduce :
Install mysql-server-5.7 package without providing a root password.
Connect to mysql from the system root account
And then run the mysql commands :
mysql> select authentication_string from user where host='localhost' and user='root';
+-----------------------+
| authentication_string |
+-----------------------+
| |
+-----------------------+
1 row in set (0,00 sec)
mysql> alter user root#localhost identified by 'mypassword';
Query OK, 0 rows affected (0,00 sec)
mysql> select authentication_string from user where host='localhost' and user='root';
+-----------------------+
| authentication_string |
+-----------------------+
| |
+-----------------------+
1 row in set (0,00 sec)
However, running the same command with a hashed value works :
mysql> ALTER USER 'root'#'localhost' IDENTIFIED WITH 'mysql_native_password' AS '*D7B8FEAED940F8F2A0055864C0A59782B4BCED02';
mysql> select authentication_string from user where host='localhost' and user='root';
+-------------------------------------------+
| authentication_string |
+-------------------------------------------+
| *D7B8FEAED940F8F2A0055864C0A59782B4BCED02 |
+-------------------------------------------+
1 row in set (0,00 sec)
And then, I can change the password with the original request :
mysql> alter user root#localhost identified by 'mypassword';
Query OK, 0 rows affected (0,00 sec)
mysql> select authentication_string from user where host='localhost' and user='root';
+-------------------------------------------+
| authentication_string |
+-------------------------------------------+
| *FABE5482D5AADF36D028AC443D117BE1180B9725 |
+-------------------------------------------+
1 row in set (0,00 sec)
Why does the "unhashed" version not work the first time ? Am I missing something or is this a bug in this version of MySQL ?
I am trying to move our encryption from Code to the database to speed things up. When I attempt to decrypt the information using this select statement I get an incorrect parameter count error.
SELECT AES_DECRYPT(u.strFirstName,'usa2010') FROM EncryptingTest.tblUser u;
I've looked at the documentation and this should work. Can someone tell me what I am doing wrong??
EDIT
I have tried Restarting the MySQL Server to no avail. The server Version is 5.6.22
From the example you provided it seems ok. Can you see about casting it first?
SELECT CAST(AES_DECRYPT(u.strFirstName,'usa2010') AS CHAR(50)) FROM EncryptingTest.tblUser u;
Please check this link it has some great resources on the issue your facing...
http://mysqlblog.fivefarmers.com/2014/03/27/mysql-5-6-17-now-with-better-encryption/
EDIT - The actual fix
Using AES_ENCRYPT() or AES_DECRYPT() with block_encryption_mode set to a block cipher other than ECB will produce an error if the IV is not provided:
mysql> SET ##session.block_encryption_mode = 'aes-256-cbc';
Query OK, 0 rows affected (0.00 sec)
mysql> SELECT HEX(AES_ENCRYPT('test', 'key'));
ERROR 1582 (42000): Incorrect parameter count in the call to native function 'aes_encrypt'
mysql> SELECT HEX(AES_ENCRYPT('test', 'key', RANDOM_BYTES(16)));
+---------------------------------------------------+
| HEX(AES_ENCRYPT('test', 'key', RANDOM_BYTES(16))) |
+---------------------------------------------------+
| 2EFBA8708925C1DF8B661E57938FAE5E |
+---------------------------------------------------+
1 row in set (0.00 sec)
Note that the IV isn’t itself stored in the resulting encrypted output – it’s an artifact that you’ll have to track separately to get the decrypted values back:
mysql> SET #iv = RANDOM_BYTES(16);
Query OK, 0 rows affected (0.01 sec)
mysql> SELECT HEX(AES_ENCRYPT('test', 'key', #iv));
+--------------------------------------+
| HEX(AES_ENCRYPT('test', 'key', #iv)) |
+--------------------------------------+
| 650CE9E699ECA922E09E80CEBE51BFC7 |
+--------------------------------------+
1 row in set (0.00 sec)
mysql> SELECT AES_DECRYPT(UNHEX('650CE9E699ECA922E09E80CEBE51BFC7'), 'key', #iv);
+--------------------------------------------------------------------+
AES_DECRYPT(UNHEX('650CE9E699ECA922E09E80CEBE51BFC7'), 'key', #iv) |
+--------------------------------------------------------------------+
| test |
+--------------------------------------------------------------------+
1 row in set (0.00 sec)
I notice a very weird problem in my code. I am inserting a value of 128 but in my database it says 127.
I'd like to look at the mysql general/query logs however i dont ever see any log files produce no matter what i do. I tried -l , -l with an absolute path and --general_log_file. No luck. I also used mysqladmin flush-logs. Still nothing
Are you using a signed TINYINT datatype by any chance?
CREATE TABLE my_table (id TINYINT);
Query OK, 0 rows affected (0.03 sec)
INSERT INTO my_table VALUES (128);
Query OK, 1 row affected, 1 warning (0.00 sec)
SELECT * FROM my_table;
+------+
| id |
+------+
| 127 |
+------+
1 row in set (0.00 sec)
We are using MySql 5.0 on Ubuntu 9.04. The full version is: 5.0.75-0ubuntu10
I created a test database. and a test table in it. I see the following output from an insert statement:
mysql> CREATE TABLE test (floaty FLOAT(8,2)) engine=InnoDb;
Query OK, 0 rows affected (0.02 sec)
mysql> insert into test value(858147.11);
Query OK, 1 row affected (0.01 sec)
mysql> SELECT * FROM test;
+-----------+
| floaty |
+-----------+
| 858147.12 |
+-----------+
1 row in set (0.00 sec)
There seems to be a problem with the scale/precision set up in mySql...or did I miss anything?
UPDATE:
Found a boundary for one of the numbers we were inserting, here is the code:
mysql> CREATE TABLE test (floaty FLOAT(8,2)) engine=InnoDb;
Query OK, 0 rows affected (0.03 sec)
mysql> insert into test value(131071.01);
Query OK, 1 row affected (0.01 sec)
mysql> insert into test value(131072.01);
Query OK, 1 row affected (0.00 sec)
mysql> SELECT * FROM test;
+-----------+
| floaty |
+-----------+
| 131071.01 |
| 131072.02 |
+-----------+
2 rows in set (0.00 sec)
mysql>
Face Palm!!!!
Floats are 32 bit numbers stored as mantissa and exponents. I am not 100% sure how MySql will split the storage but taking Java as an example they would use 24 bits for a signed mantissa and 8 bits for an exponent (scientific notation). This means that the maximum value a FLOAT can have is +8388608*10^127 and the minimum is -8388608*10^127. This means only 7 significant digits, and my FLOAT definition used 8.
We are going to switch all of these 8,2 to DOUBLE from FLOAT.
MySQL docs mention "MySQL performs rounding when storing values" and I suspect this is the issue here. I duplicated your issue but changed the storage type to be DOUBLE:
CREATE TABLE test (val, DOUBLE);
and the retrieved value matched the test value you provided.
My suggestion, for what it's worth, is use DOUBLE or maybe DECIMAL. I tried the same original test with:
CREATE TABLE test (val, DECIMAL(8,2));
and it retrieved the value I gave it: 858147.11.