During an upgrade of rails version in my application from 4.1.8 to 4.2.0, I have encountered the following issue.
String literals in where conditions are now additionally wrapped into quotation marks, which
then become part of a query string, delivering no valid results anymore. This happens only for database fields of a text type (varchar fields are not affected). I am using a MySQL database.
> Table.where(column: 'data')
[08:19:20.822552] Table Load (0.3ms) SELECT `table`.* FROM `table`
WHERE `table`.`column` = '\"data\"'
Now, if you have a row containing data value in a column row, this condition will no longer match (obviously, "data" is not a match anymore).
In Rails 4.1.8 everything worked perfectly fine:
> Table.where(column: 'data')
[08:19:58.303366] Table Load (0.4ms) SELECT `table`.* FROM `table`
WHERE `table`.`column` = 'data'
I don't know if this is a default or a configurable behaviour. I somehow haven't found a corresponding release note on that. I would be very grateful for any suggestions on what has changed and what is the best way to fix it.
Many thanks for help!
Could you try this way:
Table.where("column=?", 'data')
I guess this will work.
Related
I have quite a strange problem, I'm very new to SQL and I was doing a free course in SQL
I'm actually learning the "SELECT" command.
So, I create my database, create some table, put some data in it with the "INSERT INTO" command
And now I want to select some data in it, but I have a strange bug (not an error) when i do
SELECT * FROM aliment;
everything work like it's supposed to do, but when I do
SELECT 'nom','calories' FROM aliment;
Something strange happens.
Instead have a list of all the specific data i'm looking to get i just get a list with all the data replaced by the name of the columns.
Here 2 screen to show you what's happens:
[2
I know one it's from the terminal(and yes it's not mine but from a video) and mine is from the software, but it's still had to work no?
You have a typo in your SQL. Use backticks (on the same key as ~ on a US keyboard) around your column names, not '. Using a single quote (an apostrophe) makes it a literal value, not a column name.
SELECT `nom`,`calories`FROM aliment;
I have a problem in querying a CSV (with header) file using Drill.
If I run the following code:
SELECT Bid, Last FROM table(dfs.`/data/bb_20020201.csv` (type => 'text', fieldDelimiter => ',', extractHeader => true));
I got an error code corresponding to the word "Last". If I query another column instead of Last everything works nice.
I think the problem is because Last is also a SQL command.
I would really appreciate any help on this issue.
It seems Last is reserved keyword in Drill. Enclose it in a back-ticks:
SELECT Bid, `Last` FROM ...
https://drill.apache.org/docs/lexical-structure/#identifiers
Or change identifier quotes to double quotes or brackets if you need:
https://drill.apache.org/docs/lexical-structure/#identifier-quotes
If it helps you, you can create a Jira ticket to add Last to reserved keywords table:
https://drill.apache.org/docs/reserved-keywords/
I'm having trouble building a query in Access 2013. The database isn't mine and the only thing I really have control over is this query. There is a table, I'm pulling 7 fields from it and eventually adding an 8th field to the query to do some string manipulation.
However, I keep getting getting "Syntax error in date in query expression 'fieldname'." error whenever I click on the arrow to sort the fields. The odd thing is these errors pop up when sorting non-date fields. When sorting the date field I get "Syntax error (missing operator) in query expression 'Release Date'."
This happens after a fresh build. I have no WHERE conditions, just SELECT and FROM. Ideas?
Here's the sql query, though I'm mainly working in the query design view:
SELECT Transmissions.[Job#], Transmissions.[Part#], Transmissions.TransmissionSN, Transmissions.Status, Transmissions.[Release Date], Transmissions.[Build Book Printed], Transmissions.[ID Tags Required]
FROM Transmissions;
Well... it seems you are the lucky inheritor of a poorly designed database.
Using special characters in a field name is just asking for trouble. And you've found what that trouble is.
Access uses the # sign to designate a Date type for query comparisons. Such as:
dtSomeDate = #2/20/2017#
You surround the date with the # signs.
In your case, the query thinks [Job#] and [Part#] are trying to wrap dates. But of course, that's not the case and thus it fails.
You can try a couple of work arounds. (I leave it to you to experiment.)
1) You can try to rename the problem fields within your query. So that:
Transmissions.[Job#] becomes Transmissions.[Job#] as JobNum
and
Transmissions.[Part#] becomes Transmissions.[Part#] as PartNum
2) You can try to copy the [Transmissions] table to a new table that you create
that does not have the naming problems.
3) Export the [Transmissions] table to a CSV file and re-import it to a new
table (or possibly new database) without the naming problems.
Here is a link to a microsoft article that tells you why to avoid special characters in Access:
Big Bad Special Chars.
Hope that puts you on the right track. :)
Typically, this means that the field names are missing or misspelled.
Try running this to see:
SELECT * FROM Transmissions;
I'm trying to replicate the following LIKE query using a full text search on JSON data;
SELECT * FROM table
WHERE response LIKE '%"prod_id": "foo"%'
AND response LIKE '%"start_date": "2016-07-13"%'
In my database the above query returns 28 rows
This is my attempt:
SELECT * FROM table
WHERE MATCH(response)
AGAINST('+"\"prod_id\": \"foo\"",+"\"start_date\": \"2016-07-13\""')
However this returns over 4,500 rows (the same as running the first query for only the prod_id ~1,900 rows when running the first query on just the date)
It was my understanding that +"text here" would indicate a required word, and that literal double quotes (present in the JSON data) should be escaped, and that , would indicate a split between the two strings I'm looking for. What am I not understanding correctly? Is there any point in running this as a full text query anyway?
Thanks to #Sevle I've tweaked my query like so, and it's returning the correct results;
SELECT * FROM table
WHERE MATCH(response)
AGAINST('+\"prod_id: foo\" +\"start_date: 2016-07-13\"' IN BOOLEAN MODE)
The comma was not helping and I was escaping the wrong characters, and of course I did need IN BOOLEAN MODE to be added. Finally, I removed the double quotes I was searching for in the JSON string.
It may also be worth noting that as I'm using PHP PDO to run this query I also had to make the following tweaks.
Instead of constructing the query like so trying to bind the variables like I normally would;
$query = $db->prepare('...AGAINST('+\"prod_id: :prod_id\" +\"start_date: :start_date\"');
$query->execute(array('prod_id' => 'foo', 'start_date' => '2016-07-13'));
I had to do this, as I found I could not bind variables in full text searches
$sql_against = $db->quote('...AGAINST('+\"prod_id: foo\" +\"start_date: 2016-07-13\"');
$query = $db->prepare("...AGAINST($sql_against IN BOOLEAN MODE)")
In the process of moving some applications from PHP and Delphi to Java-RS some column entries are spoiling the show at this time.
After reading the data from mySQL with JPA into Java Pojos converting the result to XML using JaxB and trying to read back the result to JQuery / jqGrid a failure happens.
In the browser the problem simply shows at "not well formed".
Looking at the details with the Eclipse XML editor gives the error message:
An invalid XML character (Unicode 0x0) was found in the element content of the document
Now I'd like to proceeed and fix the original data.
How would an SQL query look like that looks for the rows that have
invalid entries?
How would an SQL query look like that fixes these
rows?
Let's assume the column with the problem is "name" in Table "Customer"
For question #1 I found:
SELECT name from customer where hex(name) like "%00";
to work. For question #2 I am assuming that update with a left substring might work. I am not sure about the length in this case. It looks like length(name) will return the length including the terminating zero character. Will the update with left(length(name)-1) work correctly in this case?
I am not sure whether backup and restore of the database would keep the current somewhat corrupted database in shape. So it would also be helpful to know how the situation can be reproduced with an insert statement that creates null terminated strings on purpose.
I think you should be able to transform the HEX() with something like
UPDATE customer SET name=UNHEX(REPLACE(HEX(name), '00', ''));
or simply
UPDATE customer SET name=REPLACE(name, CHAR(0), '');
update customer set name=left(name,length(name)-1) where hex(name) like "%00";