This is NOT MySQL who cuts your data off. Investigate your client software or programming language settings.

Can you reproduce the issue on this fiddle ?

Let's see the specific steps you used.

@RickJames - added examples. Let me know if you need more details. My hunch tells me it is some sort of default mysql setting.

Please provide SHOW VARIABLES LIKE 'char%'; SHOW CREATE TABLE testlimit; SHOW CREATE TABLE testlimit2; There may bee something subtle going on with charsets.

@RickJames - all are utf8. I added a 3rd example if it helps give clues. Also if I export the data from testlimit into excel... and import it into testlimit2... the full data is there and not trimmed. It HAS to be some "size" setting right?

@RickJames - just cuts off. There are thousands of examples in our main tables. Basically these are all comma separated fields and I try to normalize our reporting by creating a row per comma item. It could be mid word, end of word, anything. I haven't tested non comma gibberish but I can't seen how that commas would cause issues. The first step we do is take out the non used rows (in a view which is Ex1) and then we run to break up the comma items... I thought running comma script on good table would fix... no. Everything breaks (stops) at same spot.

@RickJames - there is no memory limits or anything else that could cut this off? I have some dev guys who have made changes to the config but usually they are raising a limit (unless they fat fingered something).

I don't know of any memory or settings limits. I don't need to see thousands of examples; one will probably suffice.

@Rick - added a lot more info and example. After reboot text and text/view is now working. However varchar field types over 255 seem broke broke. I don't have a ton of these but maybe 20 across 10 tables and all are broken (trimming data at same point). What is wild is that when I try to import data to update/append... It acts like the data that is trimmed is still there! I can be chastised for using varchar for a longer column but most of these turned into long columns over time.

@LOSTinDB - Use TEXT instead of VARCHAR(1000) or any other value between 256 and 64K. If you have a mismatch of CHARACTER SETs, that can cause truncation.

"Fails to import" -- need the error message or text that was attempted and what it was truncated to. "worked for YEARS" -- what version of MySQL?

@RickJames - yea switching these now... But how did it work for so long and then stop working? The character sets and these tables have had zero changes in at least 2 years and they haven't had changes in 5-6 years that have anything to do with the question.

I have lots of possible answers, but I need more info to decide which answer to give you!

@RickJames - sorry "fails to import' = [Err] [Row1] [Imp] 1406 - Data too long for column. This is after I have changed varchar(1000)... and this has worked in same environment for years across many tables.

That "before" is about 254 characters. (maybe a space got lost). It sure sounds like something when through a VARCHAR(255) at some stage. I don't see and "character set" issue in that sample.

@RickJames - my strong points are server management not mysql. I am adequate with databases... So it is painful to have a config bug and not figure it out within a couple of hours. I still have no clue what happened other than slightly happy text is working now. Text was truncated too before reboot.

TINYTEXT is limited to 255, too.

@RickJames - yea knew right away it was chopped at 255... just didn't understand why. Still don't. I have never used tinytext for anything. I still don't get how tables I have had running for years get chopped off (starting this week because last Friday was fine), obviously truncated columns, I import the right data and it acts like the data is already there even though it isn't showing it all. I am so confused. At least my username is fitting!

So the bug is contagious too. Because if I take a table from last Friday that shows everything and I turn the column type from varchar(1000) to TEXT... it works but chops off everything at 255. It is like those tables are corrupt now. Luckily it is pretty fixed data or it might be hard to replicate. The thing is these 10 tables that have this issue create like 50 views/tables (jobs).

SHOW CREATE TABLE; show the commands used to transfer the data; etc.

@RickJames - I didn't create a new table. I just took a copy of the "good" table - last Friday and edited the column type to TEXT. When I saved and refreshed, it chopped off all of the columns that were varchar(1000).

@RickJames - Do you want me to run a specific test? I can do whatever. Anything you want I have probably done but can do it again to get more info.

You can get the CREATE for an existing table. That would be a good start. Then, what were the steps of "saved and refreshed"?

@RickJames - I checked and all of the tables are utf8. However there is no default character set defined in my.ini.... been this way for years.

Please provide the SHOWs I asked for yesterday.

@RickJames - that is one of our main tables - the show at the bottom of the question. I did check the other tables... they basically all look like this.