I have a Laravel app which manages articles. These articles have a content section, which is being stored within the database as string (varchar). It worked properly when I did not put in some big content, but now it says:
String data, right truncated: 1406 Data too long for column 'content' at row 1
How am I supposed to store the content in the database as HTML?
Laravel supports the text, mediumText and longText column types which resolve to the respective MySQL equivalent.
An appropriate migration entry for your instance would be:
$table->text('content');
You need to expand the size of the content column in the database. This means change the type from varchar to text.
Related
I have a PHP web application developed with CakePHP 4 an MySQL.
One of the databases the application works with is a table named trg_registros_vip that contains 77 columns. One of the columns is named trg_tipo_proyecto and is defined as a non-nullable varchar with a maximum length of 100 characters.
The table is populated by reading an excel file with SimpleXLSX (a library obtainable as shuchkin/simplexlsx by using composer). For each row in the file, starting from the second row (as the first one has the headers for the sheet), the data on each cell from left to right, starting from the first cell, is stored in an entity class named TRegistrosVip in the same order as defined for each column in the table starting from the second (since the first column is an autoincremental primary key). Then the entity is inserted in the table. The column trg_tipo_proyecto is the fifth one in the table and the data for this column is obtained from fourth column in the excel file.
However, when I try to read the excel from the application, I get the following error message: Error: [PDOException] SQLSTATE[22001]: String data, right truncated: 1406 Data too long for column 'trg_tipo_proyecto' at row 1 in C:\xampp\htdocs\CPSC2\vendor\cakephp\cakephp\src\Database\Statement\MysqlStatement.php
The stacktrace for this error indicates that the error is generated in the very moment I try to insert one row in the table.
I searched in the excel file if there is a cell in the fourth column whose length is greater than 100 and got none.
I searched the table class associated to the entity class, named TRegistrosVipTable in case of a bad defined column and I got this:
$validator->scalar('trg_tipo_proyecto')
->maxLength('trg_tipo_proyecto', 100)
->requirePresence('trg_tipo_proyecto', 'create')
->notEmptyString('trg_tipo_proyecto');
That means the column is well defined.
I check the config/app.php file in case I would be working with a wrong database but I'm using the correct one.
Also, due to possible presence of foreign accents, I called the utf8_decode function on each value of that column in the excel file before inserting it on the table.
Considering the described above, what would be the cause of this error?
Thanks in advance.
SOLVED
I implemented logging in the application and printed in the debug log file the value in the excel file's fourth column for each row after the call to the utf8_decode function. The error is triggered when trying to insert the word "Regularización" (without the double quotes, without leading or trending spaces and with an accent).
I removed the accent from that word in the Excel and the error dissappeared.
However, I cannot remove the accents from the Excel programmatically because client's restrinctions forbid it. So, I tested removing the call to utf8_decode and inserting the value directly without any codification or decodification. The error is not triggered anymore.
Thanks to all who have read and answered this question.
I am writing a Innodb plugin. In the plugin code I declared the type of the column as "MYSQL_TYPE_FLOAT" and when I am feeding a float value to it via 'table->field[m] -> store(f1, TRUE);' where f1 = 3.145 its cropping.
In my case it made it 3 instead of the expected 3.145.
So please suggest me how to feed float without cropping.
I have done with my question.The solution is while defining the fields for the plugin table we have to take MYSQL_TYPE_FLOAT as type for column and the value we are going to feed in this column must be of type double for getting the proper value in the table.
Basically just as the title says, in MySQL can I specify a specific range of values for a column so a choice can be selected when a record is added.
I am only starting to understand MySQL and I know that you can do this MS-Access. I'm not sure but do I have to put something special in the 'Length/Values' column when designing? If I can do it, where do I specify what values would be selectable?
If not, is there a more efficient work around then creating a new table and relating the specified values as a foreign key.
Cheers
MS Access combines a few functionalities into a single program:
A database engine (MS Jet)
A programming environment with a programming language (VBA)
A table editor
A table data editor
A form editor
A report editor
A query editor
... more
MySQL is a database engine only. So there is no natural "Select Box" to input data. This would need to come from your programming environment or form generator.
That said, there is support for such a data type: Use ENUM - e.g. CREATE TABLE test (saluation ENUM ('Mr.', 'Mrs.'));
I am saving data in a mysql database. This data is an array and the content is different data of the current user that is logged in to my system.
I do this when I save to the database:
$data = addslashes(serialize($array));
then
"UPDATE or INSERT INTO TABLE SET ... data = '$data';"
Now, the data are saved correctly since the insert or update statement return valid from my php code.
My problem is when I try to un-serialize it, it returns false and a notice is shown in my page.
What am I doing wrong?
I will bet the field in your mysql database is not big enough to save all the characters. That is why, when you un-serialize it you get an notice and nothing in return.
Try to increase the field to a MEDIUMBLOB or MEDIUMTEXT (maximum length of 16,777,215) or LONGBLOB or LONGTEXT (maximum length of 4,294,967,295) like this:
ALTER TABLE your_table MODIFY COLUMN column_name MEDIUMTEXT /* other properties*/;
And try to save and read your data again.
Now, if your data is over 4,294,967,295 (which is LONGBLOB or LONGTEXT), maybe you should check what kind of data you saving and maybe filter or remove unwanted some.
After you're getting the data from the table, are you removing the slashes before unserialize function.
Try inserting without the addslashes() and add slashes before it's taken to the array.
I would like to store some articles (blog posts) in a mysql table, these posts will be made from more parts (e.g.: part1, part2 ... part x)
I don`t know how to store them...
Could I store each part in a text file, or how could I store it in a mysql database ?
What field can support data of this size ?
And how should I design the table to store each part of the post ?
It would be good to store each part in the same cell and just separate them with a word () and then cut it with php ?
Thanks!
A common design method is to create a "Parts" table, ex:
CREATE TABLE parts (page_id INTEGER, part_name VARCHAR(255), body TEXT);
which will work fine at lower traffic. (page_id in this case is the foreign key to the page which "owns" this part - you'd get all parts for a given page by saying, natch SELECT * FROM parts WHERE page_id = :some_page_id)
As your traffic rises, the cost of pulling in and assembling the pages may become egregious, in which case the splitting apart the body contents from a larger text field (as you suggested) would not be a terrible idea. At this level, the speed gains from doing direct serialization of a hash into the database column and making the app server's CPU bear the brunt of the work (as opposed to the DB server) may be worth it.
The column types you'd be interested in are enumerated here under "Storage Requirements for String Types": http://dev.mysql.com/doc/refman/5.0/en/storage-requirements.html
Summarized, TEXT (64KB) should be large enough to hold most basic data. MEDIUMTEXT (16 MB) or LONGTEXT (4096 MB) if your data is noticeably large or you foresee it growing. BLOB, MEDIUMBLOB or LONGBLOB (same sizes as the *TEXT types) if you intend to do any PHP variable deserialization from DB columns.
I'd suggest one table "Post" and second table "Post_part" with FK to "Post". In the "Post_part" table you could store the text in column of TEXT type.