I was connecing to Mysql database via Mysql jdbc connector 5.1.15.
The table contains quoted identifiers( column name with special characters). I need to insert values into table. I was trying to get the Metadata of the database and tried to get the storesLowerCaseQuotedIdentifiers(), storesMixedCaseQuotedIdentifiers and storesUpperCaseQuotedIdentifiers.
Among the three storesMixedCaseQuotedIdentifiers returns false where as storesLowerCaseQuotedIdentifiers and .storesUpperCaseQuotedIdentifiers returns true. If Mysql supports both upper and lower case quoted identifiers then it can return true for MixedCaseQuoted identifier. Why it is returning true for both Loqwer and UppercasequotedIdentifiers?
Thanks in advance. Correct me if I am wrong.
Related
I am trying to add to a table called Users in an Access database I have created. I am using the following code to do it (which has been copied from here):
import pyodbc
def createAccount():
conn = pyodbc.connect(r"Driver={Microsoft Access Driver (*.mdb, *.accdb)};DBQ=myPath\User Database.accdb;")
cursor = conn.cursor()
cursor.execute("""
INSERT INTO Users(Username, Password, Chips)
VALUES("User 5", "Pass 5", 7800)""")
conn.commit()
but I get this error:
pyodbc.Error: ('07002', '[07002] [Microsoft][ODBC Microsoft Access Driver] Too few parameters.
Expected 2. (-3010) (SQLExecDirectW)')
I've seen other posts which say to check spelling of all names used and there isn't anything wrong there. So why isn't this code working?
There are some subtle differences in default behaviour between Access SQL queries executed from within the Access application itself (MSACCESS.EXE) and queries executed from external applications via the Access ODBC driver or the Access OLEDB provider.
From within Microsoft Access itself, both double-quotes (") and single-quotes (') can be used to delimit string literals. This has been true since the earliest versions of Access.
However, the ODBC driver and OLEDB provider at least try to more closely conform to ANSI SQL, so single-quotes (') are used to delimit string literals while double-quotes (") are used to delimit table and column names. Therefore "User 5" will be interpreted as a column name or a parameter name depending on whether such a column actually exists.
I am trying to enter a default value of a string row in my database, using ASP.NET Visual Studio. I am simply trying to have "NotSet" as default but I get this error when trying to update the database:
The name "NotSet" is not permitted in this context. Valid expressions
are constants, constant expressions, and (in some contexts) variables.
Column names are not permitted.
I still have trouble understanding what kind of values are permitted, though. The datatype is "nchar(10)" and nulls are allowed. There's nothing else to it.
Make sure NotSet is in quotes in your sql statement
'NotSet'
I was using the data type enum() but I got this error in mysql workbench
Each value must be quoted between single quotes, and they must be separated with commas. For example:
ENUM('Value1','Value2','Value3')
I have a MySQL table with a VARCHAR(100) column, using the utf8_general_ci collation.
I can see rows where this column contains arbitrary byte sequences (i.e. data that contains invalid UTF8 character sequences), but I can't figure out how to write an UPDATE or INSERT statement that allows this type of data to be entered.
For example, I've tried the following:
UPDATE DataTable SET Data = CAST(BINARY(X'16d7a4fca7442dda3ad93c9a726597e4') AS CHAR(100)) WHERE Id = 1;
But I get the error:
Incorrect string value: '\xFC\xA7D-\xDA:...' for column 'Data' at row 1
How can I write an INSERT or UPDATE statement that bypasses the destination column's collation, allowing me to insert arbitrary byte sequences?
Have you considered using one of the Blob data types instead of varchar? I believe that this'd take a lot of the pain away from your use-case.
EDIT: Alternatively, there is the HEX and UNHEX functions, which MySQL supports. Hex takes either a str or a numeric argument and returns the hexadecimal representation of your argument as a string. Unhex does the inverse; taking a hexadecimal string and returning a binary string.
The short answer is that it shouldn't be possible to insert values with invalid UTF8 characters into VARCHAR column declared to use UTF8 characterset.
That's the design goal of MySQL, to disallow invalid values. When there's an attempt to do that, MySQL will return either an error or a warning, or (more leniently?) silently truncate the supplied value at the first invalid character encountered.
The more usual variety of characterset issues are with MySQL performing a characterset conversion when a characterset conversion isn't required.
But the issue you are reporting is that invalid characters were inserted into a UTF8 column. It's as if a latin1 (ISO-8859) encoding was supplied, and a characterset conversion was required, but was not performed.
As far as working around that... I believe it was possible in earlier versions of MySQL. I believe it was possible to cast a value to BINARY, and then warp that in CONVERT( ... USING UTF8), and MySQL wouldn't perform a validation of the characterset. I don't know if that's still possible with the current MySQL Connectors.
If it is possible, then that's (IMO) a bug in the Connector.
The only way I can think of getting around that characterset check/validation would be to get the MySQL sever to trust the client, and determine that no check of the characterset is required. (That would also mean the MySQL server wouldn't be doing a characterset conversion, the client lying to the server, the client telling the server that it's supplying valid UTF8 characters.
Basically, the client would be telling the server "Hey server, I'm going to be sending UTF8 character encodings".
And the server says "Okay. I'll not do any characterset conversion then, since we match. And I'll just trust that what you send is valid UTF8".
And then the client mischievously chuckles to itself, "Heh, heh, I lied. I'm actually sending character encodings that aren't valid UTF8".
And I think it's much more likely to be able to achieve such mischief using prepared statements with the old school MySQL C API (mysql_stmt_prepare, mysql_stmt_execute), supplying nvalid UTF8 encodings as values for string bind parameters. (The onus is really on the client to supply valid values for bind parameters.)
You should base64 encode your value beforehand so you can generate a valid SQL with it:
UPDATE DataTable SET Data = from_base64('mybase64-encoded-representation-of-my-value') WHERE Id = 1;
Here's my scenario. I save a bunch of Strings containing asian characters in MySQL using Hibernate. These strings are written in varbinary columns. Everything works fine during the saving operation. The DB contains the correct values (sequence of bytes). If I query (again using Hibernate) for the Strings that I saved I get the correct results. But when Hibernate fills the entity to which the Strings belong with the values from the DB I get different values then the ones I used in the query that retrieved them. Instead of receiving the correct values I receive a bunch of FFFD replacement characters.
For example: if I store "하늘" in the DB and then I query for it, the resulting String will be \uFFFD\uFFFD\uFFFD\uFFFD\uFFFD\uFFFD.
the DB connection has the following parameters set useUnicode=true&characterEncoding=UTF-8,
I've tried using the following configurations for Hibernate but that didn't solve the problem:
- connection.useUnicode = true
- connection.characterEncoding = UTF-8
By the way, this all works fine if the MySQL columns are of type varchar.
What am I missing? Any suggestions?
Thanks
Set the connection character set to be binary too:
SET NAMES 'binary';