I am currently working on our MySQL Database and am in need of help. Would be happy if you have a solution! :)
We are generating automatic invoices with text. The text is very long and contains customerinformation and other fields of the database.
Currently we are using a long concat function which is so long that you can't see through. I would like to have a function that takes a string with placeholders (like php sprintf function) with values and formats the text.
For example (pseudocode)
FILLTEXT("Customer %s has payed invoice %s on %s",customername,invoicenumber,invoicepaydate) as Invoice_text
(We are using a lot of columns and a much longer text, I just wanted to do a quick example).
I am very grateful for any help or advices!
Thanks
I have a SQL query that returns a value similar to "7 KI" for a description column, but when I export my data to a .csv/text file using SQLCMD, the resulting data is "7KI" (no space inbetween 7 and K). I believe that this causes a formatting issue when I open this csv file in Excel later on...(I'm wondering if "7K" is getting read as 7,000 because the data is splitting into a new column as-if it contained a comma there?)...
This is so weird to me. I am using the Quotename function to return the Unicode version of this description field in the first place - do you think that's why I am experiencing this issue? I used the Quotename function to fix issues with this field a few days ago. To me, it's odd that the export is stripping the space inbetween 7 and K in the first place.
Has anyone ever seen/fixed this before? It really looks like there is a space included in the SQL data, and I copied-and-pasted the value into a online Unicode converter to confirm there is a space. Why would a random space be getting stripped in the SQLCMD export? Plenty of my other text fields are not having this issue, even though they have spaces too (although not followed by "K"...) so maybe the issue is with CMD somehow reading the value...?
I'm having trouble building a query in Access 2013. The database isn't mine and the only thing I really have control over is this query. There is a table, I'm pulling 7 fields from it and eventually adding an 8th field to the query to do some string manipulation.
However, I keep getting getting "Syntax error in date in query expression 'fieldname'." error whenever I click on the arrow to sort the fields. The odd thing is these errors pop up when sorting non-date fields. When sorting the date field I get "Syntax error (missing operator) in query expression 'Release Date'."
This happens after a fresh build. I have no WHERE conditions, just SELECT and FROM. Ideas?
Here's the sql query, though I'm mainly working in the query design view:
SELECT Transmissions.[Job#], Transmissions.[Part#], Transmissions.TransmissionSN, Transmissions.Status, Transmissions.[Release Date], Transmissions.[Build Book Printed], Transmissions.[ID Tags Required]
FROM Transmissions;
Well... it seems you are the lucky inheritor of a poorly designed database.
Using special characters in a field name is just asking for trouble. And you've found what that trouble is.
Access uses the # sign to designate a Date type for query comparisons. Such as:
dtSomeDate = #2/20/2017#
You surround the date with the # signs.
In your case, the query thinks [Job#] and [Part#] are trying to wrap dates. But of course, that's not the case and thus it fails.
You can try a couple of work arounds. (I leave it to you to experiment.)
1) You can try to rename the problem fields within your query. So that:
Transmissions.[Job#] becomes Transmissions.[Job#] as JobNum
and
Transmissions.[Part#] becomes Transmissions.[Part#] as PartNum
2) You can try to copy the [Transmissions] table to a new table that you create
that does not have the naming problems.
3) Export the [Transmissions] table to a CSV file and re-import it to a new
table (or possibly new database) without the naming problems.
Here is a link to a microsoft article that tells you why to avoid special characters in Access:
Big Bad Special Chars.
Hope that puts you on the right track. :)
Typically, this means that the field names are missing or misspelled.
Try running this to see:
SELECT * FROM Transmissions;
I've written a MySQL script to create a database for hypothetical hospital records and populate it with data. One of the tables, Department, has a column named Description, which is declared as type varchar(200). When executing the INSERT command for Description I get an error:
error 1406: Data too long for column 'Description' at row 1.
All the strings I'm inserting are less than 150 characters.
Here's the declaration:
CREATE TABLE Department(
...
Description varchar(200)
...);
And here's the insertion command:
INSERT INTO Department VALUES
(..., 'There is some text here',...), (..., 'There is some more text over here',...);
By all appearances, this should be working. Anyone have some insight?
Change column type to LONGTEXT
I had a similar problem when migrating an old database to a new version.
Switch the MySQL mode to not use STRICT.
SET ##global.sql_mode= 'NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION';
Error Code: 1406. Data too long for column - MySQL
There is an hard limit on how much data can be stored in a single row of a mysql table, regardless of the number of columns or the individual column length.
As stated in the OFFICIAL DOCUMENTATION
The maximum row size constrains the number (and possibly size) of columns because the total length of all columns cannot exceed this size. For example, utf8 characters require up to three bytes per character, so for a CHAR(255) CHARACTER SET utf8 column, the server must allocate 255 × 3 = 765 bytes per value. Consequently, a table cannot contain more than 65,535 / 765 = 85 such columns.
Storage for variable-length columns includes length bytes, which are assessed against the row size. For example, a VARCHAR(255) CHARACTER SET utf8 column takes two bytes to store the length of the value, so each value can take up to 767 bytes.
Here you can find INNODB TABLES LIMITATIONS
in mysql if you take VARCHAR then change it to TEXT bcoz its size is 65,535
and if you can already take TEXT the change it with LONGTEXT only if u need more then 65,535.
total size of LONGTEXT is 4,294,967,295 characters
Varchar has its own limits. Maybe try changing datatype to text.!
Turns out, as is often the case, it was a stupid error on my part. The way I was testing this, I wasn't rebuilding the Department table after changing the data type from varchar(50) to varchar(200); I was just re-running the insert command, still with the column as varchar(50).
If your source data is larger than your target field and you just want to cut off any extra characters, but you don't want to turn off strict mode or change the target field's size, then just cut the data down to the size you need with LEFT(field_name,size).
INSERT INTO Department VALUES
(..., LEFT('There is some text here',30),...), (..., LEFT('There is some more text over here',30),...);
I used "30" as an example of your target field's size.
In some of my code, it's easy to get the target field's size and do this. But if your code makes that hard, then go with one of the other answers.
For me, I defined column type as BIT (e.g. "boolean")
When I tried to set column value "1" via UI (Workbench), I was getting a "Data too long for column" error.
Turns out that there is a special syntax for setting BIT values, which is:
b'1'
With Hibernate you can create your own UserType. So thats what I did for this issue. Something as simple as this:
public class BytesType implements org.hibernate.usertype.UserType {
private final int[] SQL_TYPES = new int[] { java.sql.Types.VARBINARY };
//...
}
There of course is more to implement from extending your own UserType but I just wanted to throw that out there for anyone looking for other methods.
Very old question, but I tried everything suggested above and still could not get it resolved.
Turns out that, I had after insert/update trigger for the main table which tracked the changes by inserting the record in history table having similar structure. I increased the size in the main table column but forgot to change the size of history table column and that created the problem.
I did similar changes in the other table and error is gone.
I try to create a table with a field as 200 characters and I've added two rows with early 160 characters and it's OK. Are you sure your rows are less than 200 characters?
Show SqlFiddle
There was a similar problem when storing a hashed password into a table. Changing the maximum column length didn't help. Everything turned out to be simple. It was necessary to delete the previously created table from the database, and then test the code with new values of the allowable length.
If you re using type: DataTypes.STRING, then just pass how long this string can be like DataTypes.STRING(1000)
In my case this error occurred due to entering data a wrong type for example: if it is a long type column, i tried to enter in string type. so please check your data that you are entering and type are same or not
For me, I try to update column type "boolean" value
When I tried to set column value 1 MySQL Workbench, I was getting a "Data too long for column" error.
So for that there is a special syntax for setting boolean values, which is:
UPDATE `DBNAME`.`TABLE_NAME` SET `FIELD_NAME` = false WHERE (`ID` = 'ID_VALUE'); //false for 0
UPDATE `DBNAME`.`TABLE_NAME` SET `FIELD_NAME` = true WHERE (`ID` = 'ID_VALUE'); //true for 1
I had a different problem which gave the same error so I'll make a quick recap as this seems to have quite different sources and the error does not help much to track down the root cause.
Common sources for INSERT / UPDATE
Size of value in row
This is exactly what the error is complaining about. Maybe it's just that.
You can:
increase the column size: for long strings you can try to use TEXT, MEDIUMTEXT or LONGTEXT
trim the value that is too long: you can use tools from the language you're using to build the query or directly in SQL with LEFT(value,size) or RIGHT(...) or SUBSTRING(...)
Beware that there is a maximum row size in a MySQL table as reported by this answer. Check documentation and InnoDB engine limitations.
Datatype Mismatch
One or more rows are of the wrong datatype.
common sources of error are
ENUM
BIT: don't use 1 but b'1'
Data outlier
In a long list of insert one can easily miss a row which has a field not adhering to the column typing, like an ENUM generated from a string.
Python Django
Check if you have sample_history enabled, after a change in a column size it must be updated too.
Every week, I have to completely replace the data in several very large MySQL tables. So what I normally do is delete the existing data, import the new data, and then run my usual queries to modify the new data as needed.
Unfortunately, these days I have noticed that the new data contains unwanted characters, such as quotes and extra spaces. With well over 100,000 records in some of these tables (AFAIK), I cannot easily open the data in notepad to strip out unwanted characters, prior to importing.
I realize I could write a separate find and replace query for every single column in every table, like this:
UPDATE mytablename SET mycolumn = REPLACE(mycolumn, '"', '');
But having to name every column is a bother. Anyway, I would like to find a more elegant solution. Today, I found a snippet on the internet that looks like a start:
SELECT * FROM INFORMATION_SCHEMA.COLUMNS WHERE
table_name = 'myTable' and ordinal_position = 1
I think the next step might be to loop through the ordinal positions, and then replace and update each column, but I don't know how to do this in MySQL. I also don't know how to stop the loop after the last column is reached, to avoid error messages.
Is there an easy way to do this? Or am I hoping for too much?
I am a beginner, so a clear, simple explanation would be much appreciated.
Thanks in advance.
MORE INFORMATION:
Since my first post, I have discovered that stored procedures are not allowed on my server. Too bad.
Anyway, I have tried this new code, just to get started:
set #mytablestring='mytable';
set #mycolumnnumber=1;
set #mycolumnname=(SELECT column_name FROM INFORMATION_SCHEMA.COLUMNS WHERE table_name = #mytablestring and ordinal_position = #mycolumnnumber);
SELECT #mycolumnname FROM mytable;
Unfortunately, in the final SELECT query, #mycolumnname is interpreted as a string, not as a column name. So the query does not work. If I could get past this, I believe I could write some code to loop through the columns by incrementing #mycolumnnumber.
If anyone knows how to solve this, I would really appreciate some help.
Many thanks.
I suggest that you take a look at vim, sed, awk and many of the other text editors and text processing utilities that you can find on Linux (and sometimes on Windows too). 100,000 records may be a pain in Notepad, but it's a piece of cake for real text processing utilities.
For example, to strip all # characters from foobar.txt:
sed 's/#//g' foobar.txt > foobar-clean.txt
Or, the same thing with the file opened in (g)vim:
:%s/#//g