PHP MySQL insert dropping data - php

Ok this is a new one for me. Basically I have a table articles:
id: int auto increment
title: varchar(200)
description: varchar(1000)
ctext: longtext
chtml: longtext
Now I do an insert into this table with mysql_query:
INSERT INTO articles
(title, description, ctext, chtml)
VALUES
('$title', '$description', '$text', '$html')
All values have been passed through mysql_escape_string().
The text and html here are roughly 50k in size (so I can't really post the fully query here).
Now, here's the problem: the query works. A new row is inserted. However the ctext and chtml columns are empty. This is MySQL 5.0.51a and PHP 5.2.8. No errors are raised of any kind as far as I can tell.
Now I dumped the query out to a file in /tmp and ran it with:
mysql -u username -p dbname < /tmp/query
Same thing.
I copy the query into Navicat and it... works.
So what on earth is going on?

Some random thoughts:
Have you tried controlling the text length see if it only fails at one point?
What kind of connection are you opening? Which driver?
Have you checked the encoding of your connection? Some invalid characters might be sent in.
Have you tried using parameters instead of mysql_escape_string?
Have you tried executing directly from the same file from Navicat instead of using the copy-paste? Again, might be related to an invalid character that's not passed through the copy-paste but was saved in the file.
Just to cover the basics we so often forget, how do you verify that the data is not inserted? I mean, how to you visualize it? You could have a line break that hides the first lines from 2 out of 3 means of visualization. Just a long shot, but I've seen it happen.
Addition: MySQL connections defaults to latin1, you need to use something like mysql_query("SET NAMES 'utf8'") to transfer unicode characters.

I'm not sure if this matters, but mysql_escape_string is deprecated and replaced by mysql_real_escape_string
Have you tried it with smaller text?

Related

Unable to insert square root string in my mysql database

I want to insert similar text into mysql table.
It is inserted in table but it insert like 42=(-4)2=16 ..
I want to insert it properly with square root symbol.
I guess MySQL proper collation type might be the solution but don't know which collation it may work.
As you described you tried the right collation (utf8_unicode_ci), it is not a MySQL issue. You may see the previous discussion on how to store unicode in mysql on stackoverflow.
Following these answers, I executed the followed queries:
CREATE TABLE can_square ( sqr CHAR(100) CHARACTER SET utf8 COLLATE utf8_unicode_ci);
INSERT INTO can_square (sqr) VALUES ( "4² = (-4)² = 16" );
And it works fine.
And I inserted the same type of data from my PHPMyAdmin successfully, both from running an SQL query and inserting manually in the insert tab. Then it also is not a PHPMyAdmin issue
As yourself spotted, its probably a string formatting issue when you copy and paste from another source. Try to type the string directly in PHPMyAdmin and see if it works. If you have to put the value manually, and you know it is happening, copy and paste may not be a good alternative.

What exactly does "Can't send long data for non-string/non-binary data types" mean?

I am attempting to INSERT a single file's data into a LONGBLOB column via PHP along with some other data like the file's name, size in bytes, sha256 checksum, etc.
I know there is nothing wrong with the table itself, as I am able to INSERT the file and the rest of the columns all at once through phpMyAdmin which suggests that I use the following MySQL INSERT statement:
INSERT INTO DB_NAME.TABLE_NAME (SHA256SUM, FILE_NAME, FILE_DATA) VALUES (?, ?, ?)
So my PHP code currently looks like this:
$mysqli_query = 'INSERT INTO DB_NAME.TABLE_NAME (SHA256SUM, FILE_NAME, FILE_DATA) VALUES (?, ?, ?)';
$stmt = $mysqli->prepare($mysqli_query);
$null = NULL;
$stmt->bind_param("ssb", $sha256sum, $_FILES['career_application_FILE_UPLOAD']['name'], $null);
$stmt->send_long_data(0, file_get_contents($_FILES['career_application_FILE_UPLOAD']['tmp_name']));
$stmt->execute();
Which is pretty much exactly what Oracle suggests right here.
But for some reason it just hasn't been working for me. (And trust me, I have been trying for the past 3 hours.)
It kept returning the general MySQL error "COLUMN FILE_DATA CANNOT BE NULL".
So I enabled NULL values on the FILE_DATA column, and then the INSERT would work, but the FILE_DATA column (which is supposed to be filled with BLOB data) just reads NULL.
So I disabled NULL values on the FILE_DATA column and I placed a $stmt_error = $stmt->error; line just after the send_long_data section and I caught the following error:
Can't send long data for non-string/non-binary data types
I tried deciphering what that meant, and was unable to, so here I am asking for help.
I'm going to get some sleep, and hopefully in the morning I can answer my own silly question... I just have this feeling that it's something so entirely obvious I am too tired to notice it right now.
Some details:
I am running this code on Debian 8 and NGINX v1.6.2
I have quadruple-checked that my MySQL max_allowed_packet is set to the default 16776192 (which shouldn't matter anyways, as the files I am attempting to upload are a few bytes to a few kilobytes in size)
I have attempted uploading all different types of files (txt, mov, png, pdf, etc)
I am not unfamiliar with PHP or MySQL at all, I have been working with them both for over 10 years now
I even tried setting the LONGBLOB collation to binary, since the entire table's collation was ascii... but it wasn't possible to change the LONGBLOB collation, nor should it matter since like I said originally... phpMyAdmin has no problem inserting file data into the LONGBLOB column)
Thanks for reading.
In my stupidity, I failed to read the spec for send_long_data in it's entirety and just assumed that 0 was an insignificant placeholder for something.
It's not insignificant.
It was meant to be 2. To equate to the 3rd parameter of the MySQL INSERT.

A single character is giving error: "Data too long for column" when using PDO with MySQL - Why?

I'm using PHP to suck up a CSV file, massage the data, and then import it into a MySQL InnoDB table using PDO.
The table and all varchar columns have a utf8_unicode_ci collation, and are utf8.
I have a column that is varchar(1).
When I attempt using PDO to do a certain query, I'm getting SQLSTATE 22001 Data too long for column 'HeatingOption' at row 1 error.
The query is as follows:
INSERT INTO `Config`.`BaseItemCodes`
(`BaseItemCode`, `Series`, `HeatingOption`, `StandardColor`)
VALUES ('BD1896-1W', 'BD18', 'w', 'BG')
It's interesting to me, because I'm debugging, and having PDO print out the query to the CLI. I copy/pasted the query, without modification, directly into MySQL Workbench and executed it just fine.
I'm currently creating the value from extracting it from the end of the BaseItemCode there. I'm using substr(), trim()ing it, and strtolower()ing it as well, just to make sure of everything.
The PHP script is utf8 w/o BOM, and so is the CSV file.
I'm on Windows 8.1 using PHP 5.5.7, and running MySQL 5.6.15 on a CentOS server.
I'm thinking it's some strange charset issue, but I'm not sure what to look at next.
Edit: I just attempted to change the column to 'char(1)' and it didn't help.
Edit 2: I increased the length of the column to varchar(20) and I was able to insert the data.
I'm changing my question to "Why do MySQL and PDO behave this way?"
Edit:
I double checked the data after inserting the row and increasing the length of the column, and it seems the name of the bind :HeatingOption was being passed through. So PDO wasn't binding the data for some reason, yet to be discovered.
the error clearly said it,
you should go to your database and change the lenth of that column HeatingOption to more then 1 , put it forexample varchar(25)
EDIT:
it should work with VARCHAR(1) or CHAR(1) however you may inserted spaces with this letter
example 'w '
^---//this spaces will be counted as bite, and it will be too long

Php code igniter save turkish characters to my sql

I am writing a web app using PHP Codeigniter. I receive input that can be in any language and I save it in my DB.
The MYSQL DB collation is set to utf8_unicode_ci.
For codeigniter in the database.php I have set this:
$db['default']['char_set'] = 'utf8';
$db['default']['dbcollat'] = 'utf8_unicode_ci';
When I run the following insert on my DB:
insert into user (name,id) values ('John Temirtaş', 2)
I get this error:
Incorrect string value: '\xC5\x9F' for column 'name' at row 1
There is a problem with the s. Its a turkish character.
So far I have tried this while debugging
print_r($name)
John Temirtaş
print_r("Encoded Name: ".utf8_encode($name))
Encoded Name: John TemirtaÅ
print_r("Decoded Name".utf8_decode($name)
Encoded Name: John Temirta?
print_r("Decoded-Encode Name: ".utf8_decode(utf8_encode($name)))
Decoded-Encode Name: John Temirtaş
I have tried saving John TemirtaÅ in the db and it works fine. So I think I might utf8_encode($name) before saving it in the DB and utf8_decode before displaying it. Just doing the latter will NOT work. YOU NEED TO ADD mb_internal_encoding("UTF-8"); to the top of your php script.
How do I encode the data properly so that its inserted?
THANK YOU EVERYONE FOR YOU HELP HERE IS WHAT WORKED!
Open up MySql work bench. Set the
character encoding and collation of
the user table. Charset: utf-8
Collation: utf8_unicode_ci
Set the collation of the name column
to utf8_unicode_ci. Done. The
insert should work.
Thank you for all your help.
Before running your insert query, try running the following query first:
mysql_query("SET NAMES 'utf8'");
and seeing if that helps.
You did everything okay. I am from turkey and in every project I develop I am checking these things:
Is my php file saving with UTF8 encode?
Are my tables and its fields collated with utf8_unicode_ci
Do not change codeigniter's "char_set" and "dbcollat" options.
If you do these, there should be no problem.
Try this before inserting record in databse.
$this->db->db_set_charset('latin1', 'latin1_swedish_ci');
// -> latin1- Charset &
// -> latin1_swedish_ci - Collation
Make sure you have same setting in DB for table as well as for table column.
Maybe I cannot answer exactly to what you are asking but I can give a few general tips cause I use utf-8 my self.
Try entering this character by hand from some client (heidisql is a free one).
When I worked with GET things didn't work well but with htmlencode, htmlspecialchars.. with such functions it works fine.
Later I only worked with POST so no encoding required and I have implemented an utf-8 autocomplete that works fine.
I thing it is worth to try the encoding thing and var_dump sql just before insert in order to make sure what is entered.
In some complex situtation quotes stored in variables have come very handy to me, for example:
$dbq="\"";
$sql=$dbq .'some sql '. $dbq;
I work with PHP PDO and never had a problem with utf-8 so far. Hope any of this is of some help!
I forgot.. you said codeIgniter.. entering a value by hand will assure you at least where to focus, db or framework (luckily I use mine mvc). Just try to get very inside into the mvc code and see what does sql look like just before insertion.

Mysql - Insert queries inserting funny characters

I have a simple script which inserts values from a text file into a mysqldatabase - however some accented characters aren't inserted properly. Like lets say I have a word:
Reykjavík
I try to insert it using a simple insert sql statement and instead I this value ends up in the database????
Reykjavík
How do I fix this?
====EDIT====
I tried to change the collation - the thing is that I'm using navicat here and if I lets say try to insert any such word with accentuated characters like this using the navicat QUery generator or panel it is inserted perfectly with no problem whatso ever - however my php script when it runs a similar query end s up putting trash in the table :( whats going on here...
The set of questions marks is because you are inserting a character whose encoding is not understood by MySQL. Try collating with utf8_bin. This should work.

Categories