Hi I want to insert all escape characters in a column in MySQL. I can not insert \ always because a long data may have a lot escape characters.
Thanks
Sunil Kumar Sahoo
I am not sure if I am getting this correct but you
have a lot of data
you want to insert them into database with regular SQL commands
most of data requires escaping.
So you have no much options. Since there is no direct binary mode in MySQL you
either execute SQL script with escaping
you will write parametrized queries and insert data directly with some custom tool you will write.
If choosing first approach have a look at MySQL manual for some escaping string details. Particularly you may escape one backslash \ with double backslashes \\ sequence. Also have a look at NO_BACKSLASH_ESCAPES, which eliminates need for escaping completly.
Related
I have a large file that contains a mysqldump of a database. I searched for all the semicolons I come up with 378. When I upload the file to phpMyAdmin it reports 379 queries when doing an import. (I know that phpMyAdmin might not be reliable, but I just want to make sure I don't have a problem with the output of mysqldump)
Is there a way to find out what it thinks the extra query is? The dump file is pretty large and I don't want to share the information.
EDIT:
I have posted the database schema at:
http://blastohosting.com/pos_database.sql
It would be great if it could be determined to as why there is an extra query being reported by phpMyAdmin
I can't tell you why, necessarily, but I can say that I got exactly the same results: 378 semicolons, "379 queries executed".
However, here's the weird thing: when I removed the last two lines in the script:
(blank)
-- Dump completed on 2014-02-17 17:52:43
...PMA said "378 queries executed". It's evidently counting that final comment as a "query" even though it's ignored.
A dump file doesn't necessarily contain one semicolon per statement.
Any CREATE TRIGGER or CREATE PROCEDURE or CREATE FUNCTION statements have literal semicolons within their bodies, so it is common practice to change the client's statement terminator to something besides semicolon, to resolve the ambiguity.
So you could be counting semicolons that aren't statement terminators. Likewise, MySQL may recognize more SQL statements executed that didn't use semicolon.
MySQL builtin commands such as DELIMITER, CHARSET, USE, SOURCE, etc. don't need a terminator at all, but they may have one without error. They shouldn't be reported as statements executed by the server, but they may throw off your count of semicolons.
Do you have any semicolons inside string literals or SQL comments?
I have used backticks (`) in some SELECT queries to escape fields such as 'first-name'. This will work on MySQL. These queries are run through a DBO class in a php application and I would like the application to be able to use other database servers, such as MSSQL and Posgres.
What is the best approach for allowing problematic field names to be used across all of these database servers? I was thinking of taking the fields as an array and quoting them with the escaping character that is appropriate to each.
[EDIT]
To clarify: I am building a tool that will be used to map configurations stored within the php application to the fields of an external database. I wanted to escape these as a precaution because I have no idea what field names will actually be mapped to and used within the queries.
The solution is very simple: do not use reserved words as identifiers. It makes the code more difficult to read anyways.
If you really need to use such words (as in "there is some obscure reason beyond your control"), you can just prefix all your identifiers by an arbitrary character, such as _ for example.
The cross-DBMS mechanism (as defined in SQL-92 and other standards) is using double-quoted delimited identifiers. According to this reference it's widely supported.
It's worth nothing that MySQL allows to enable/disable this syntax so you still need to ensure that session settings are correct before issuing any query.
MySQL uses backticks (`) by default, but can be configured to support proper ANSI quoting.
IMO: If you're connecting to MySQL, set it to ANSI mode, and while you're at it enable every STRICT option it has. It becomes much easier to write code that's portable against it then.
Of course, the best option has to be not using reserved words, but the list of reserved words can change over time so rigorous quoting isn't such a bad idea.
The proper way of escaping is not to use field names that need escaping.
If you still have to use escaping - use ". It is the standard one (defined by ANSI SQL).
Postgres and Oracle understand " escaping. But i do not know about MSSQL an MySQL.
In the following SQL statement, SQLite sorts correctly but MySQL does not:
However, if I don't include the quotation marks around the field names, it works correctly:
Can anyone explain the behavior that MySQL but not SQLite would not sort correctly if a field is defined with quotation marks?
"TotalOrders" (with double quotes) is a constant string - ordering by it doesn't do anything ... in essence you get the unsorted sequence of rows, which might seem to be correctly sorted.
You want
ORDER BY `TotalOrders`
with backticks. which is the column identifier.
In addition to Eugen's answer:
It might be worth noting that this behaviour depends on the configuration of MySQL.
The described behaviour only shows if MySQL is left in the default - non standard compliant configuration.
If it's configured to run in "ANSI mode" the double quotes are not used for string literals but for identifiers (as nearly all other DBMS).
Another solution to the problem would have been to make MySQL comply with the SQL standard by changing the SQL_MODE to "ANSI".
Then standard compliant single quotes are used for literals and the double quotes are used for identifiers.
I am trying to update a field using
UPDATE table set field='some_variable' where id=1;
The problem here is that the some_variable comtains data with multiple special characters in it. so I am not able to use 'some_variable' or "some_variable" as it breaks and fails when it encounters the first same character(' or "). How can I overcome this?
Thanks.
Mike
There are two solutions, the first is to use mysql_real_escape_string() the second is to use prepared statements. You have not mentioned what your programming language is but it's sure to support either prepared statements or real escape.
In addition to real escape, if your field is a char or varchar you should modify your query as follows:
UPDATE table set field='some_variable' where id=1;
Generally, you just need to escape the reserved characters -- see MySQL docs for specific reference. If you are directly executing the query (ie: in mysql shell), you'll have to escape manually. Most languages will supply a function to escape for you -- in PHP, for example, it's mysql_real_escape_string().
Does MySQL allows to create database which has dot (.) in its name?
I'm using MySQL 5.1.22.
You can't use the dot in a database name. Also, I'd avoid using it in any identifier. A common convention is to use underscore instead. It will serve the same purpose and will avoid a LOT of confusion. If you do have a good reason for using strange and otherwise-illegal characters in a table or field name, then you have to escape it.
to escape identifiers in MySQL, use the backtick:
SELECT `select`, `some.field name`, `crazy()naming+here`
FROM `my-=+table`
Getting into the habit of backticking all field names regardless of whether you need to is a good practice in my opinion, but that's another story.
You can use . in names from MySQL 5.1.6 according to the documentation.
However, as has been said and will said again, please don't do it. For every problem you think you're solving now you'll be creating five which will bite you later on. Since . is used to qualify names - e.g. database.table or table.column you'll have to quote your database name every time you use it.*
You can do this with backticks:
CREATE TABLE `do.not.do.this` (col INT);
or using double quotes if you set the following option:
SET sql_mode='ANSI_QUOTES';
CREATE TABLE "asking.for.problems" (col INT);
* Not strictly true - you have to quote any character that's not alphanumeric or _ or $ , but . is a particularly troublesome option to have in your names.
Before MySQL 5.1.6, database and table names cannot contain /, \, ., or characters that are not allowed in file names (see 8.2. Schema Object Names).
In versions after 5.1.6 you have to quote your tablename with a backtick (`) - but as others also advised: you shouldn't do this to prevent any unnecessary trouble.
MySQL 5.0.22 doesn't appear to allow it:
% mysqladmin -uroot -pXXX create foo.bar
mysqladmin: CREATE DATABASE failed; error: 'Incorrect database name 'foo.bar''
Even it if it did allow it, I would strongly recommend against it.
At the very least you'd have to escape any reference to that database with backticks in every single query that ever uses it.