Ok, I am trying to store data in a MySQL database from an Android app. I use PHP as the go between.
What I submit to the database is this (for example):
Sakè
What is stored in MySQL is:
Sakè
When I print the line back out in Android it knows to convert back to:
Sakè
The problem is, when I do certain select statements, yeah it basically doesn't work out like it should. Is there any way I can keep this consistent?
Just a note in MySQL: I use utf8_general_ci
You need to enforce correct character for your database connection for your PHP scripts. Simplest approach would be to execute this query:
SET NAMES 'utf8';
just once, best after you connect(). If you use Zend Framework, just add this:
resources.db.params.charset = UTF8
to your application.ini. For mysqli see set_charset(). If you use anything else, check the docs for something similar. If there's nothing, the SET NAMES trick would always work.
One important note though - depending on how you put your data to the DB, your database content most likely require fixing as it is corrupted by broken charset during INSERTs. So if even you do SET NAMES now, you most likely still see old data shown wrong. But that is, ironically, OK - you are now showing all fine, but data itself is broken. You just now need to fix your data (just re-insert it).
Related
I'm not really sure why I'm having this issue but at the moment I'm blocked. The problem that I'm having is that when using Doctrine to insert into MySQL, some values are automatically escaped. For example, on a form where a user inputs something such as he/she, the data stored into the MySQL table is he\/she.
Now, the issue is that sometimes the user will use a search function, but using he/she won't give them any results. How can I solve this? I'm thinking on escaping the characters on the string that I pass to the LIKE function, is this a correct approach? I'm thinking that the same issue will happen if the user has values such as this is 50% (the percent would need to be converted as well before given to the LIKE function?)
You need to solve this at the core - the data should never enter into your database. A probable cause of this is a misconfigured web server that still has magic quotes enabled with MSSQL mode, or using a library that tries to do input sanitation in a (very) wrong way. You should never ever ever want to fix this on the search end of things - once you start patching there for corrupted data you're in for an endless cesspool of problems.
Debug why the data is going in wrong, and fix it there.
First, I have read and googled on this issue extensively using various combinations of the the search terms php pdo or mysql database name escape. Sadly, I have not found anyone dealing with this same issue.
I have a mysql database with a schema named www.company.com
Generally this is not an issue, as it can easily be escaped using the back tick character.
However, when using mysqli or PDO to call a stored procedure in that schema, it always returns:
PROCEDURE www.company.com.usp_stored_procedure_name does not exist
Obviously, this is a simple mater of putting ` characters around the www.company.com however I cannot find away to do this using either mysqli or PDO. I have also failed to find reference to this issue in the documentation.
I should also point out that this procedure runs just fine from mysql command line client or from MySQL Workbench as in those cases I can include the back ticks or a use statement. Furthermore, I've already verified that this is not related to database user permissions.
However, every time I try to use the stored procedure through mysqli or PDO I receive the error above.
As this procedure is responsible for ETL operations and returns multiple results sets, converting it to individual statements called from php would be very painful. I am desperately hoping that someone has dealt with this problem before.
The following are some of the methods tried:
Note: back-tick nesting seems to cause a mess w/ the forum, so I've used the '-' character in place of a `
I've tried using an escaped database name when calling to mysqli_connect...
$mysqli=mysqli_connect($host, $this->db->username, $this->db->password, '-www.company.com-');
...and received an error.
I've tried calling the stored procedure w/o a database name...
$mysqli->multi_query("CALL usp_stored_procedure_name(50, '2013-05-01')");
...and received the error referenced above.
I've tried calling the stored procedure w/ a database name...
$mysqli->multi_query("CALL -www.company.com-.usp_stored_procedure_name(50, '2013-05-01')");
...and received the error referenced above.
We have an app based on JSF and JBoss that stores textual data into a regular PostgreSQL database. When we are using our system via the JSF application, everything works perfectly, (i.e. we are able to retrieve, save and do everything else through the system).
We also have a PHP website, however, that retrieves information from the same database. The problem is that when it asks for information from any column of type TEXT, the database only outputs a series of numbers (it is using the value as if were a BLOB or CLOB, I think). Because when I look directly into the database, I see the same number.
How should I go about solving this?
I think that you would only need to emulate something like a CLOB if you are storing so much text that a streaming API made sense. I have yet to see a case for this in PostgreSQL, but if you did, you could use LOB's and just unescape in your app (they are basically BLOB's).
To pull a value from the db, it is generally well documented in PHP's documentation, but if you are using the pg_ functions, keep in mind that they do not loop over the result set for you (you need to do that yourself). The modules in PEAR etc. may wrap that for you so make sure to consult your framework's documentation.
My MySQL Server (running with PHP via PDO on Windows 2008 Server) returns error code 1406 (data too long for field) when inserting strings longer than allowed in a column. The thing is I read somewhere that what MySQL usually truncates the data when it is not in strict mode. I changed the sql_mode in my.ini so that even at startup it doesn't enter in strict mode (it is currently ""), but it is still giving me the error and rolls back, so the data is lost (truncating is the desired behaviour of the site).
I entered to the command line and made an insert with a long string in a shorter varchar field and it does truncate the data and save, but it is the site that doesn't. When I changed the mode back to strict, it didn't truncate in the command line (only the error).
Also, I made the site output the current sql mode, both global and session (##GLOBAL.sql_mode and ##SESSION.sql_mode) and they both output "" but just don't work as desired.
Does anyone know what is causing this and/or how to change it?
My suspicion is that it may have to do with PDO enabled with PDO::ATTR_ERRMODE = PDO::ERRMODE_EXCEPTION, but I have read and can't find anything helpful about that (I don't really think this is definitely the explanation, but I am just putting this out there so that you know as much as possible about the problem).
Thank you very much
You should not really do that - please don't let bad data into your database, and sanitize it in your scripts before you insert.
If you don't know actual width of your VARCHAR columns or don't want to hard-code it in your scripts, you can read it from database by querying INFORMATION_SCHEMA table COLUMNS using query like this:
SELECT
column_name,
data_type,
character_maximum_length,
ordinal_position
FROM information_schema.columns
WHERE table_name = 'mytable'
(you may want to limit this to only data_type = 'varchar').
Having this information and specifically character_maximum_length, you can use PHP substr to trim your input strings to desired length.
Advantage of this approach is that it does not alter any server configuration, and should work for any other databases, not only MySQL.
But if you insist on doing it unsafe way, you can try to temporarily disable strict mode by executing this:
SET sql_mode = '';
After that MySQL should silently trim strings. Read more here.
Probably the mysql server is in "not forgiving" mode, aka. traditional (most times). What you read is true, if mysql server operates in forgiving mode. If you are trying to insert too long string, it can be really important information, therefore mysql will issue a error. You have a few alternatives:
1: Use insert ignore (which will transform all errors into warnings and will proceed to truncating the data)
2: For the current session, set the sql_mode to ''
With either of these your problem should go away.
PS: I have read the error you are getting, but i still think the server is operating in traditional mode (so it's no mistake that i recommended sql_mode set to empty).
PS2: After changing the my.cnf, did you restart the mysql server?
I am working with a legacy PHP framework and am coming across some strange behavior that I can't track down.
I'm running a query that looks something like this
select * from table where column like '%word-anotherword%'
, which I would like to return records from table where column contains the text "word-anotherword". (column is a longtext field).
When I run this query in phpMyAdmin, I get the expected results. But when I run it from inside our framework, I get no results. I have run it in a separate .php file, using mysql_link, mysql_query to run the query, and that also behaves as expected.
When I echo out the query in the framework directly before it is passed to mysql_query, it is formatted just the same as I expect. I.E. our framework is not escaping it in some unexpected manner.
I am assuming that our framework is overriding some PHP setting somewhere to cause this difference in behavior, but I have had no luck googling for what it might be. I found this article, which seemed to be a good start, but also didn't quite seem to fit what I'm seeing, since I am getting different behaviors on the same MySQL setup.
Any pointers in the right direction would be greatly appreciated!
As a debugging heads-up:
When you echo your query out, you might want to make sure you're actually seeing the data - e.g. if you're echo-ing onto a webpage, make sure you're applying htmlspecialchars() to the string. Otherwise you might not spot some changes.
LIKE is not full text search, that's why question title is wrong and, probably, that article which you found isn't related to your problem.
And about your problem, open your my.cnf and enable queries log:
[mysqld]
#Set General Log
log = "C:/all_queries.log"
Now run your query and look into log.