I got a multi-use SQL table in my SQL Server 2008 database. It can store only 100 characters as value.
Now I want to store a value in it that has more than 100 characters. Is it possible to zip or compress a text with SQL Server functionality?
If your column is defined as VARCHAR(100), it can hold a maximum of 100 characters. There's no "magic" or "compression" that makes this go away.
Yes, SQL Server has text compression - to reduce the disk space used. But if the column is limited to 100 characters, it can store no more than 100 characters.
If you need more - you need to define a column with a larger capacity. There's no other solution.
It's very easy to change a column's datatype, too - so if you need to, you should be able to just issue a SQL statement like:
ALTER TABLE dbo.YourTable ALTER COLUMN YourColumn VARCHAR(150)
and now your column can store up to 150 characters. This is a non-destructive change, e.g. existing data will not be affected (not wiped out or deleted).
Related
We are storing data in an Innodb table having varbinary column. However, our data size requirement has grown to over 1 MB and hence I converted the column to longblob.
alter table mytable modify column d longblob;
Everything seems to be working as expected after I converted the column. However, I like to know from people who have done it earlier if anything more is required other than just converting column as shown above, especially
is there any MySQL / MariaDB version specific issues with longblob that I should take care of. There is no index on the column.
We use mysqldump to take regular backup. Do we need to change anything since the blob storage mechanism seems to be different than varbinary.
Any other precautions/suggestion.
Thank you for your guidance
[Edit: my mistake, read the wrong column for the type, the one I'm inserting into is LONGTEXT, not varchar(190)]
I am working with an application that stores the majority of its information in a MySQL database (MySQL server 5.7). One particular value I'm looking at has a 255 character limit enforced by the GUI but, when I looked at that column in the table where it's stored, it's set to varchar(190). I confirmed that I can enter 255-character values in the GUI and that they are not truncated, as I expected.
How can a varchar(190) column store >190 characters? Are there any consequences to doing it this way?
I read 11.4.1 The CHAR and VARCHAR Types and it states that anything over the limit should be truncated.
The answer is that I can't. Misread the column types because that column is varchar(255) when the application builds the schema in PostgreSQL. It's longtext* in MySQL, which explains why I was able to get past the 190 characters. I tried inserting my 230 char test string into the varchar(190) column and it throws an error, as expected.
Need more coffee.
*not sure why longtext, when the application GUI limits input to 255 characters, but I'll need to ask the people who built it.
I just changed a nvarchar(MAX) field in a table to nvarchar(250).
Could someone please tell me what happens to the data if there was an entry larger than 250 characters?
My concern is not with the visible data, but what happens behind the scenes:
What is done to the data which overshoots the limit of that container
of data?
I read in a few places that the table has to be deleted and re created again. Is this true and why? I didn't see any errors which the others received.
Is there a way to recover the truncated data after making this change? (I dont want to do it, but I'm curious)
If you have altered/changed column nvarchar(MAX) field into nvarchar(250) and you did not receive any error, it means that none on rows contains the data more than 250 characters that why SQL server successfully changed the column length and your data is accurate/complete.
If any of row contains more than 250 characters then SQL server will give you an error and alter statement will be failed. It means that data type length will not be changed.
Msg 8152, Level 16, State 13, Line 12 String or binary data would be
truncated. The statement has been terminated.
While altering column length if SET ANSI_WARNINGS OFF then SQL server will change the column length without any warning and extra data will be truncated.
By Default, it is SET ANSI_WARNINGS ON to warn the user.
I think Once data is truncated it can't be recovered later.
The system should prevent you or at least warn you of possible data loss when changing column length if any row exceeds the new length.
Depending on DBMS and version, you may even not be able to change column length.
However, if you don't have any rows exceeding 250, as you said, then there should be no problem.
There is no way to recover truncated data unless you have access to a database backup that's just before the change
On a side note, regardless of what you intend to do with that change, I should suggest to avoid columns of variable-length
MySQL automatically reserves maximum-possible length for a variable-length column, regardless of whether a row is 15 characters or 45 or 250.
This, as you can imagine, eventually leads to bottlenecks in the system.
(Maybe you don't have a database large enough for this to show effects, but my motto is "forewarned is forearmed" )
I am trying to run this query but there are no values being retrieved , I tried to find out the length of characters till which values are returned. Length was 76 characters.
Any suggestions?
SELECT tokenid FROM tokeninfo where tokenNumber = 'tUyXl/Z2Kpua1AvIjcY5tMG+KlEhnt+V/YfnszF5m1+q8ngYvw%L3ZKrq2Kmtz5B8z7fH5BGQXTWAoqFNY8buAhTzjyLFUS64juuvVVzI7Af5UAVOj79JcjKgdNV4KncdcqaijPQAmy9fP1w9ITj7NA==%';
The problem is not the length of the characters you select, but in the characters, which are stored in database field itself. Check the tokenNumber field in your database schema - if it is varchar, or blob or whatever type, what is the length, etc...
You can insert/select pretty much more than 76 characters in any database, but you can get less that 76, as in your case, it depend on how you handle the field they are stored in.
A quick way to see the tokeninfo table properties is to run this query:
SHOW COLUMNS FROM tokeninfo;
If the data types differ from what you expect them to be based on a CREATE TABLE statement, note that MySQL sometimes changes data types when you create or alter a table. The conditions under which this occurs are described in Section 13.1.10.3, Silent Column Specification Changes.
the max size would be limited by the variable max_allowed_packet
so, if you do a
show variables like 'max_allowed_packet'
it will show you the limit. By default, it is set to
1047552 bytes.
If you want to increase that, add a line to the server's
my.cnf file, in the [mysqld] section :
set-variable = max_allowed_packet=2M
and restart mysql server.
I am working on an application to dynamically generate mysql tables from Excel files.
Current I am stuck because some of the column names in the Excel files have more than 64 characters, while in mysql the maximum length for column names are 64 characters.
I thought about setting up another table to store the column names but then I will have to perform some joint operation to retrieve them.
Is there any clever way to workaround this problem?
MySQL is an open source project. You can download the source code, change things, and build your own version.
I haven't read MySQL source, but the odds are good that the maximum length of identifiers is a compile-time constant. It might be as simple as finding that constant, changing it, and recompiling. (Simple doesn't necessarily mean easy, though.)
It really is pretty easy in PostgreSQL. The PostgreSQL docs even tell you the name of the constant, and which file it's in. (NAMEDATALEN, in src/include/pg_config_manual.h)
Personally, I think you're better off fixing the Excel column names to conform to MySQL limits.
There is no other way to increase the length of the column size more than 64. here are some standards. you cant go beyond this limit.
Identifier Maximum Length (characters)
Database 64
Table 64
Column 64
Index 64
Constraint 64
Stored Program 64
View 64
Alias 256
Compound Statement Label 16
And you cant retrive the column names through join operation. through join operation you can only achieve data of 2 or more tables. the solutio to your problem is that you should truncate the column names in excel already before exporting them to mysql.