I just want to know if that querys are case sensitive or not. Are the same these querys?
SELECT * FROM Users WHERE login="john";
SELECT * FROM Users WHERE login="John";
SELECT * FROM Users WHERE login="JOHN";
SELECT * FROM Users WHERE login="jOHn";
I have tried that on my console and all of them worked, but I want to be sure of that if I would use Hibernate or anything else.
Thanks!
According to the MySQL docs,
The default character set and collation are latin1 and
latin1_swedish_ci, so nonbinary string comparisons are case
insensitive by default
As to the second part of you question - this SO answer shows you how to configure to have the searchers be case sensitive.
From MariaDB docs, it depends on OS. For Windows, it's not case-sensitive. For Linux, Database, table, table aliases and trigger names are affected by the systems case-sensitivity, while index, column, column aliases, stored routine and event names are never case sensitive.
Just an example from my Linux ( Debian 10 ) Box in MariaDB (Ver.10.3.18-MariaDB-0+deb10u1 ).May be helpful for someone !!
MariaDB [niffdb]> select * from account_heads where head_desc="Fuel";
+---------+-----------+
| head_id | head_desc |
+---------+-----------+
| 1 | Fuel |
+---------+-----------+
1 row in set (0.004 sec)
MariaDB [niffdb]> select * from account_heads where head_desc="FUEL";
+---------+-----------+
| head_id | head_desc |
+---------+-----------+
| 1 | Fuel |
+---------+-----------+
1 row in set (0.001 sec)
MariaDB [niffdb]> select * from account_heads where head_desc="fUEL";
+---------+-----------+
| head_id | head_desc |
+---------+-----------+
| 1 | Fuel |
+---------+-----------+
1 row in set (0.001 sec)
MariaDB [niffdb]>
Related
I'm using MySQL on a CentOS server from a website running Apache and Perl. I'm seeing this behavior (mocked up):
mysql> describe product;
+-------+------------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-------+------------------+------+-----+---------+----------------+
| id | int(10) unsigned | NO | PRI | NULL | auto_increment |
| name | varchar(10) | YES | | NULL | |
+-------+------------------+------+-----+---------+----------------+
2 rows in set (0.00 sec)
mysql> insert into product (name) values ('Widget');
Query OK, 1 row affected (0.00 sec)
mysql> insert into product (name) values ('Thing');
Query OK, 1 row affected (0.00 sec)
mysql> select * from product;
+----+--------+
| id | name |
+----+--------+
| 1 | Widget |
| 2 | Widget |
| 3 | Thing |
+----+--------+
3 rows in set (0.00 sec)
My theory is that the Perl CGI script may be executed concurrently (perhaps due to double click, browser refresh, etc.) so the insert gets performed twice. This is fairly rare but causes problems when it happens.
In cases where this happens, all columns except 'id' have identical values. Other than column 'id' duplicate values are allowed.
Is there a way to prevent this behavior?
If you installed Perl, Apache, and MySQL from CentOS repositories and didn't make any radical configuration changes, it's highly unlikely you've found a bug in the platform. Are you using mod_perl or PSGI or is it definitely CGI? Have you installed any Perl modules from CPAN sources or has everything been installed through yum?
A stupid solution you might consider implementing is generating some kind of nonce (one-time-use string or number) in your script, adding a column for it and a unique index on that column to your table, and inserting it along with the rest of the form data. If you catch a duplicate key error, just disregard it. That won't explain what's happening but it will prevent it from happening.
Is it possible to configure MySQL to return TIMESTAMP value as a UNIXTIMESTAMP by default, rather than casting every column in the SELECT statement?
MySQL has a function to convert a date to a unix timestamp.
https://dev.mysql.com/doc/refman/5.5/en/date-and-time-functions.html#function_unix-timestamp
mysql> SELECT UNIX_TIMESTAMP();
-> 1196440210
mysql> SELECT UNIX_TIMESTAMP('2007-11-30 10:30:19');
-> 1196440219
You cannot do that in MySQL configuration.
You can do that on application level - e.g. in PHP, you can use the mysqli_result::fetch_fields() method to detect timestamp type and convert it, other connectors will have similar methods.
Or you can do it - as suggested - using UNIX_TIMESTAMP() function on timestamp columns.
It sounds as though you want a different view of the same data:
mysql> select * from t;
+------+---------------------+
| data | ts |
+------+---------------------+
| foo | 2013-03-19 16:54:45 |
+------+---------------------+
1 row in set (0.00 sec)
mysql> select data, unix_timestamp(ts) from t;
+------+--------------------+
| data | unix_timestamp(ts) |
+------+--------------------+
| foo | 1363712085 |
+------+--------------------+
1 row in set (0.00 sec)
mysql> create view tv (data, time_t) as select data, unix_timestamp(ts) from t;
Query OK, 0 rows affected (0.00 sec)
mysql> select * from tv;
+------+------------+
| data | time_t |
+------+------------+
| foo | 1363712085 |
+------+------------+
1 row in set (0.00 sec)
Suppose I have a table with the following content:
mysql> select * from test;
+----+------+
| id | val |
+----+------+
| 1 | 1 |
| 2 | 1 |
| 3 | 1 |
| 4 | 1 |
| 5 | 2 |
| 6 | 2 |
| 7 | 2 |
| 8 | 2 |
+----+------+
8 rows in set (0.00 sec)
mysql>
Now I run erroneous SQL query with group by clause and without any aggregation on id column and get wrong results:
mysql> select id, val from test group by val;
+----+------+
| id | val |
+----+------+
| 1 | 1 |
| 5 | 2 |
+----+------+
2 rows in set (0.00 sec)
mysql>
Can mysql client or probably some other tool validate this query and issue error or warning on using group by without aggregation?
Yes, you can do this:
To disable the MySQL GROUP BY extension, enable the ONLY_FULL_GROUP_BY
SQL mode.
mysql> SET sql_mode = 'ONLY_FULL_GROUP_BY';
See the documentation here. Also, this section on server modules may help.
By default, the SQL Mode ONLY_FULL_GROUP_BY is set to disable. And that is the reason why your query did run without throwing any exceptions. If you don't want that behavior enable the ONLY_FULL_GROUP_BY mode,
ONLY_FULL_GROUP_BY
Setting the SQL Mode
You can set the default SQL mode by starting mysqld with the --sql-mode="modes" option, or by using sql-mode="modes" in my.cnf (Unix operating systems) or my.ini (Windows). modes is a list of different modes separated by comma (“,”) characters.
You can change the SQL mode at runtime by using a SET [GLOBAL|SESSION] sql_mode='modes' statement to set the sql_mode system value. ex: SET sql_mode = 'ONLY_FULL_GROUP_BY'
Running a fairly old version of MySQL:
mysql> SELECT ##version;
+-----------+
| ##version |
+-----------+
| 5.0.77 |
+-----------+
Afraid I'm not at liberty to update it, so I acknowledge the easy answer may be "Upgrade MySQL to a newer version."
When I do SELECT...INTO query which should return a single row with only one column I get an error:
mysql> SELECT id
INTO #active_id
FROM a_table
WHERE active = 1
LIMIT 1
;
> Undeclared variable: id
But if I add an additional column, it works fine:
mysql> SELECT id, 42
INTO #active_id, #ignored
FROM a_table
WHERE active = 1
LIMIT 1
;
> Query OK, 1 row affected (0.00 sec)
mysql> SELECT #active_id, #ignored;
+------------+----------+
| #active_id | #ignored |
+------------+----------+
| 1 | 42 |
+------------+----------+
Is there a better workaround for this? Is my syntax wrong somehow?
while using database under MySQL how can i determine my current MySQL version,database name I'm working and logged in username ?
is it possible to get through using query ?
Try this.
mysql> select version(),user(),database();
+-----------+----------------+------------+
| version() | user() | database() |
+-----------+----------------+------------+
| 5.1.41 | root#localhost | bank |
+-----------+----------------+------------+
1 row in set (0.00 sec)
SELECT DATABASE(), USER(), VERSION();
See "Information Functions" in the docs for more details