Does anyone ever use MySQL spatial buffer function successfully?
I've read the documentation here: http://dev.mysql.com/doc/refman/5.0/en/functions-that-create-new-geometries-from-existing-ones.html#function_buffer
As stated in the documentation, buffer function has 2 parameters. The first one is geometry typed, the second one is distance.
I've try to make a geometry variable
mysql> set #g1 = geomfromtext('POINT(1 1)');
Query OK, 0 rows affected (0.00 sec)
Then, to ensure that my variable is correctly set, I perform a query. If the variable not correctly set, such a query will return NULL. In this case, it is confirmed that my variable is correctly set
mysql> select astext(#g1);
+-------------+
| astext(#g1) |
+-------------+
| POINT(1 1) |
+-------------+
1 row in set (0.00 sec)
I run a query to select a buffer as stated in documentation
mysql> select astext(buffer(#g1, 5));
ERROR 1305 (42000): FUNCTION module_devel.buffer does not exist
Do I miss something here?
EDIT Sorry guys, I think I miss this:
12.17.5.3.2. Spatial Operators
OpenGIS proposes a number of other functions that can produce
geometries. They are designed to implement spatial operators.
These functions are not implemented in MySQL.
This is related to this bug report maybe. Which MySQL server are you using? Maybe you should upgrade to 5.6.
Related
I have table with:
1) Encrypted_ID varchar (256)
2) Initialization Vector(iv)varchar(256).
I would like to decrypt the column value using the key
I am using:
select Cast(AES_DECRYPT(Encrypted_ID,'Key',InitializationVector_iv)as CHAR ) as DecryptedValue from MyTable;
The result is Null.
I Also tried:
select Cast(AES_DECRYPT(AES_ENCRYPT(Encrypted_ID,'Key',InitializationVector_iv),'Key') as CHAR ) as DecryptedValue from MyTable;
The result is blob for few rows.
I'm not sure what I'm doing wrong here. Can any one help with the syntax to decrypt the column when I have:
Key
Initialization Vector value
Encrypted Column
There's actually nothing wrong with your first query, syntactically it's spot on as this worked example demonstrates.
mysql> SET ##SESSION.block_encryption_mode = 'aes-256-cbc';
mysql> create table MyTable(
-> Encrypted_ID varbinary(256),
-> InitializationVector_iv varbinary(16)
-> );
Query OK, 0 rows affected (0.93 sec)
mysql> SET #iv = RANDOM_BYTES(16);
Query OK, 0 rows affected (0.00 sec)
mysql> INSERT INTO MyTable SET Encrypted_ID = AES_ENCRYPT('hello','key', #iv), InitializationVector_iv = #iv;
Query OK, 1 row affected (0.17 sec)
mysql> SELECT CAST(AES_DECRYPT(Encrypted_ID,'key', InitializationVector_iv) AS CHAR) from MyTable;
+------------------------------------------------------------------------+
| CAST(AES_DECRYPT(Encrypted_ID,'key', InitializationVector_iv) AS CHAR) |
+------------------------------------------------------------------------+
| hello |
+------------------------------------------------------------------------+
1 row in set (0.00 sec)
As for why it's not working, I managed to get the query to return NULL in 2 scenarios. One, you get NULL returned if you use a different iv for encryption and decryption, so you might want to look at how you are storing as the iv. Two, you get NULL where you have the block_encryption_mode variable set differently when storing and trying to retrieve the value, check that you're not accidentally reverting to the default 'aes-128-ebc between sessions. There may be others...
The second query will fail because you need to supply the iv to both of he encryption and decryption functions, you only use it to encrypt. Also, since you are taking the values from the MyTable, Encrypted_ID will already be encrypted and the effect of this query would be to encrypt it again, before reversing that to get you back to the stored (encrypted) value.
Finally, AES is only going to use 16 bytes of the iv so you might as well make that VARBINARY(16).
AES doesn't work with MySQL Workbench in my case.
I have to use the mysql console.
MySql Workbench worked for me.
In my Case, encrypted value was encoded in base 64.
So I had to decode base 64 value and IV Using "From_base64" function.
SET block_encryption_mode = 'aes-256-cbc';
set #k = 'Key';
set #iv = From_base64('InitializationVector');
set #v = from_base64('EncryptedValue');
select CAST(AES_DECRYPT(#v, #k, #iv) AS CHAR);
Please make sure the encryption type, base 64 encoding, Hex/Unhex of the values/Iv are correct before you start working on the decryption.
Review MYSql functions
https://dev.mysql.com/doc/refman/8.0/en/string-functions.html
Hope this helps for someone.
SELECT * FROM plugin_referral_code WHERE code=0;
Returns this record
What!? Why?
MySQL does not return an incorrect result for that query. Please, note that most important web sites use MySQL or its forks, so it is illogical to assume that a query like that doesn't work correctly.
You are comparing potatoes with tomatoes. 'butts' is a string, 0 is a number. MySQL (or any program ever existed) cannot compare strings to numbers. So, it internally converts 'butts' to a number. Any string, if converted to a number, is 0.
Also note that your client is ignoring a MySQL warning that explains the problem:
MariaDB [test]> SHOW WARNINGS;
+---------+------+-------------------------------------------+
| Level | Code | Message |
+---------+------+-------------------------------------------+
| Warning | 1292 | Truncated incorrect DOUBLE value: 'butts' |
+---------+------+-------------------------------------------+
1 row in set (0.00 sec)
I suggest to immediately uninstall any client that hides MySQL warnings... but this is a personal opinion :)
Are you definitely executing the entire query in your query editor? I know some editors let you execute (highlighted) parts of queries. It's possible that if you're actually only executing SELECT * FROM plugin_referral_code WHERE code it would return any rows with non-NULL code values.
This is because the where clause needs to evaluate to true, and WHERE code would evaluate to true for any non-NULL code value.
That's all I can guess on this. If this is not the case, please provide more detail, e.g. what type column code is, and execute your query with DESC before it to get any query plan details.
In MySQL, an overflow creates only a warning and MySQL destroys the data you feed it:
mysql> create table tmp(data tinyint primary key);
Query OK, 0 rows affected (7.83 sec)
mysql> insert into tmp set data = 200;
Query OK, 1 row affected, 1 warning (2.27 sec)
mysql> select * from tmp;
+------+
| data |
+------+
| 127 |
+------+
1 row in set (0.00 sec)
This is a huge problem, especially when using MySQL via a programming language, where one (usually) does not check any MySQL-warnings. This may cause not only data-corruption, but data-corruption that is hidden and may remain undetected - one of the worst things that may happen in a database.
Is there a way to configure MySQL so that an overflow causes an ERROR (similar to a syntax error) and not only a warning?
See Mysql documentation
you have to activate the strict SQL mode:
If strict SQL mode is enabled, MySQL rejects the out-of-range value with an error, and the insert fails, in accordance with the SQL standard.
If no restrictive modes are enabled, MySQL clips the value to the appropriate endpoint of the range and stores the resulting value instead.
I've got a table which contains a varchar(1024) field, which in that contains strings which has hex encoded strings. This table is filled automatically and I have to provide an SP to allow users to download this, therefore, I need to change the hex back into human readable form.
If I manually run this statement (taking the Hex data from the field), it works just fine:
SELECT X'5468697320697320612074657374206D6573736167652031323334353637383930';
But I cannot find a working example of getting this to work when calling the field/column name. I've found a few examples, but these just return a null or 0.
I've tried X and UnHex() and neither give me a result.
Where am I going wrong?
Thanks
EDIT:
Okay, after doing a bit more testing, it appears it must be the way it's being written to the database in the first place.
It's a Classic ASP page that calls an SP, which creates the database entry. In this method, the write to the DB works, and I can see the HEX content in the field. Copying the content of the field, and putting this into a Select X'123123' gives me the ASCII values, as I want.
If I try this as a Select, this fails, giving me a zero or Null return.
SELECT Message_Body_Hex, UNHEX(Message_Body_Hex) FROM messages_inbound
returns:
Message_Body_Hex......unhex(Message_Body_Hex)
417265612032........(NULL)
Still confused! :)
I realize this is an old question but I ran into this same problem today and solved it using a combination of HEX and CAST. Using your example, try this:
SELECT HEX(CAST(X'5468697320697320612074657374206D6573736167652031323334353637383930' AS CHAR(33)))
When pulling from a table you'd substitute the field name:
SELECT HEX(CAST(binary_field AS CHAR(33)))
I've seen other answers recommending to use MAX in place of the 33 but this appears to work fine. Here are some sources I used:
SQL Server converting varbinary to string
and
How to convert from varbinary to char/varchar in mysql
Using the UNHEX() function seems to work fine on MySQL 5.5.29-1:
mysql> create table t1 ( f1 varchar(1024) );
Query OK, 0 rows affected (0.03 sec)
mysql> insert into t1 values('5468697320697320612074657374206D6573736167652031323334353637383930');
Query OK, 1 row affected (0.02 sec)
mysql> select f1 from t1;
+--------------------------------------------------------------------+
| f1 |
+--------------------------------------------------------------------+
| 5468697320697320612074657374206D6573736167652031323334353637383930 |
+--------------------------------------------------------------------+
1 row in set (0.00 sec)
mysql> select unhex(f1) from t1;
+-----------------------------------+
| unhex(f1) |
+-----------------------------------+
| This is a test message 1234567890 |
+-----------------------------------+
1 row in set (0.00 sec)
I am setting a variable, and then I want to use the USE command to change the database. Unfortunately USE doesn't evaluate the variable.
SET #con="testDB";
Query OK, 0 rows affected (0.00 sec)
select #con;
+--------+
| #con |
+--------+
| testDB |
+--------+
1 row in set (0.00 sec)
use #con;
ERROR 1049 (42000): Unknown database '#con'
So the value of the variable is not evaluated when I try to connect. Any ideas?
I have found my own solution, so I am going to answer my own question, in case anybody is interested.
#outis you are right, it's not possible to use a variable with the command USE.
However, due to the fact that I want to create a table in a database specified at runtime, my solution would be to use dynamic SQL:
set #schema="testDB";
set #front="CREATE TABLE IF NOT EXISTS ";
set #endpart=".`TEST1` (DIM_ID INT(16)) ENGINE = InnoDB DEFAULT CHARACTER SET = utf8 COLLATE = utf8_unicode_ci;";
set #stat=concat(#front,#schema,#endpart);
prepare command from #stat;
execute command;
So basically this solution builds up the statement, prepares it and executes it.
#schema parameter can even be past down to the script. This way I dynamically build the create statement.
I don't think it's possible to USE #var; in some way. But in some cases doing it the other way around might be an option.
USE testDB;
SET #schema = DATABASE();