I'm currently moving a large PHP-based webapp from one server to another. The old server is running MySQL 5.0.51a (on SuSE Linux), the new server is running MySQL 5.5.15 (on ArchLinux).
Now, the new MySQL is complaining about the following statement (Syntax Error):
SELECT DISTINCT(field) FROM config WHERE range='global' ORDER BY field
I did a bit of testing and found out that the following shortened statement still fails (with Syntax Error):
SELECT * FROM config WHERE range='global'
Unfortunately, this looks like perfectly legal SQL to me. My guess is that it has to do with the type of column range, which is enum('global', 'user'). Selecting from other columns, e.g. columns of type int, works perfectly fine.
I know how to fix this issue locally, i.e. adding the column name to the where-clause, like this:
SELECT * FROM config WHERE config.range='global'
But I don't want to go through the whole code, adding column names to SQL statements where appropriate.
Hence my question:
How do I tell MySQL 5.5.15 to accept the somewhat sloppy 5.0.51a syntax?
RANGE is a reserved word in mysql 5.5 see list
Protect your field, it sould work:
SELECT * FROM `config` WHERE `range`='global'
Related
I tried to get values for all views created using this sentence:
select * from information_schema.views;
but, in spite of being root, only views created by the user running previous command, are filled with values in VIEW_DEFINITION column. Rest of columns are complety filled in all cases.
Looking for information I have found this link about a bug: BUG MYSQL 39733.
Not sure if it is the expected behaviour or it is still a bug in this MySQL version (8.0.13)
In MySQL version 5.7.9 it worked fine.
I know there is a workaround: show create view testView; but I'm interesting in first command to avoid modify the code of a program using MySQL 5.7.9.
It is a MySQL version bug I think. Update your mysql.
I have installed MyBB local using XAMPP and it goes smoothly. But when I do it on the server it give me errors.
MyBB creates and inserts a lot of data by itself and I found out the errors are in queries like:
INSERT INTO... VALUES ('NULL', ...)
On my localhost MySQL (which is 5.5.27 for both) accepts this kind of query, where 'NULL' is passed as a String. But in the server it gives an error #1366 as the title says.
The problem is that changing the query is not an option since it is A LOT of queries, so anyone has an idea where I can configure this to work?
Thanks in advance.
I think your MySQL Server is running in strict mode.
This can be fixed in one of two ways, but you may have to get your hosting company to do this for you.
Method 1:
Open the "my.ini" file within the MySQL installation directory and look for something like...
# Set the SQL mode to strict
sql-mode="STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"
Replace with:
# Set the SQL mode to strict
sql-mode="NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"
Method 2:
You may be able to run an SQL query within your database management tool such as phpMyAdmin which can normally be found from your web hosting control panel:
SET ##global.sql_mode= '';
The problem is that for MySQL (in this case) 'NULL' is not the same as NULL.
Due to the fact that the column is expecting numeric data your statement does not work while the following would work:
INSERT INTO ... VALUES (NULL, ...)
... maybe you can change the MySQL mode the server is running on.
I'm fixing a bug in a proprietary piece of software, where I have some kind of JDBC Connection (pooled or not, wrapped or not,...). I need to detect if it is a MySQL connection or not. All I can use is an SQL query.
What would be an SQL query that succeeds on MySQL each and every time (MySQL 5 and higher is enough) and fails (Syntax error) on every other database?
The preferred way, using JDBC Metadata...
If you have access to a JDBC Connection, you can retrieve the vendor of database server fairly easily without going through an SQL query.
Simply check the connection metadata:
string dbType = connection.getMetaData().getDatabaseProductName();
This will should give you a string that beings with "MySQL" if the database is in fact MySQL (the string can differ between the community and enterprise edition).
If your bug is caused by the lack of support for one particular type of statement which so happens that MySQL doesn't support, you really should in fact rely on the appropriate metadata method to verify support for that particular feature instead of hard coding a workaround specifically for MySQL. There are other MySQL-like databases out there (MariaDB for example).
If you really must pass through an SQL query, you can retrieve the same string using this query:
SELECT ##version_comment as 'DatabaseProductName';
However, the preferred way is by reading the DatabaseMetaData object JDBC provides you with.
Assuming your interesting preconditions (which other answers try to work around):
Do something like this:
SELECT SQL_NO_CACHE 1;
This gives you a single value in MySQL, and fails in other platforms because SQL_NO_CACHE is a MySQL instruction, not a column.
Alternatively, if your connection has the appropriate privileges:
SELECT * FROM mysql.db;
This is an information table in a database specific to MySQL, so will fail on other platforms.
The other ways are better, but if you really are constrained as you say in your question, this is the way to do it.
MySql may be the only db engine that uses backticks. That means something like this should work.
SELECT count(*)
FROM `INFORMATION_SCHEMA.CHARACTER_SETS`
where 1=3
I might not have the backticks in the right spot. Maybe they go like this:
FROM `INFORMATION_SCHEMA`.`CHARACTER_SETS`
Someone who works with MySql would know.
I have a blocking problem with my mysql dabatase.
I have a php website with a MySql database.
Everything works fine.
I just put a sql dump from one old database server to a new database server and since, on this new server I have a weird behaviour:
A query like:
select * from toto where date(myDateField) between '2001-01-01' and '2012-01-01';
Does not work. What I mean is that it does not return any results (no errors either).
If I do the following :
select * from toto where myDateField between '2001-01-01' and '2012-01-01';
It works.
I tryied to see if on my new server my mysql system variables are different but all seems the same.
The weird thing is that on this new server I allready put another dump last week and everything worked juste fine.
Now I have no idea.
I cannot go and modify all my php files, since the website works fine on others servers. I just want to find the problem and the explanation.
Anyone has any hint on this?
UPDATED:
I have done more tests.
I have 2 databases on the same server.
On the first one (created a older dump) everything it's fine.
On the second one (created using a recent dump file) I have the problem.
So I don't really know what could be the problem.
First check the which format do u get in your server
select date(myDateField) from toto
Based on the format use between condition ... the date format may change form server to server i.e dd//mm//yyyy or yy//mm/dd check that ....
I finally managed to make it work. I installed the same dump on a different linux distribution and now it works. Before I had Gentoo and now I have Ubuntu.
So it must be something wrong on Gentoo.
I use Kettle for some transformations and ran into a problem:
For one specific row, my DatabaseLookup step hangs. It just doesn't give a result. Trying to stop the transformation results in a never ending "Halting" for the lookup step.
The value given is nothing complicated at all, neither it is different from all other rows/values. It just won't continue.
Doing the same query in the database directly or in a different database tool (e.g. SQuirreL), it works.
I use Kettle/Spoon 4.1, the database is MySQL 5.5.10. It happens with Connector/J 5.1.14 and the one bundled with spoon.
The step initializes flawlessly (it even works for other rows) and I have no idea why it fails. No error message in the Spoon logs, nothing on the console/shell.
weird. Whats the table type? is it myisam? Does your transform also perform updates to the same table? maybe you are locking the table inadvertantly at the same time somehow?
Or maybe it's a mysql 5.5 thing.. But ive used this step extensively with mysql 5.0 and pdi 4.everything and it's always been fine... maybe post the transform?
I just found the culprit:
The lookup takes as a result the id field and gave it a new name, PERSON_ID. This FAILS in some cases! The resulting lookup/prepared statement was something like
select id as PERSON_ID FROM table WHERE ...
SOLUTION:
Don't use underscore in the "New name" for the field! With a new name of PERSONID everything works flawlessly for ALL rows!
Stupid error ...