I created a simple table yesterday using the code below:
create table DepartmentYT (
Department_ID int,
Department_Name varchar (255))
I then added the data below to it (which fits in the max character length for the Department name above):
insert into DepartmentYT
values
(1, 'IT'),
(2, 'Sales')
However, when I ran this query today, nothing was returned from the table
select * from DepartmentYT
So I tried to insert the data back in:
insert into DepartmentYT
values
(1, 'IT'),
(2, 'Sales')
But I got an error message that said "String or binary data would be truncated.
The statement has been terminated" which I understand occurs when you're trying to insert data that exceeds the max length specified for the data type.
I then ran this code to check the max length for the characters and noticed that the DepartmentName varachar data type now had a max character length of 1 instead of the 255 that I'd specified yesterday.
select * from information_schema.columns
WHERE TABLE_NAME = 'DepartmentYT'
COLUMN_NAME DATA_TYPE CHARACTER_MAXIMUM_LENGTH
Department_ID int NULL
Department_Name varchar 1
Does anyone know why this may be?
I could drop the table and re-create it, but I'd like to know why the problem may have occurred and if anyone has experienced something similar / may know why it occurred.
Thanks in advance!
Still not sure why the max character length changed, but I used this statement to increase the length
alter table DepartmentYT alter column Department_Name varchar (255) NULL;
then I re-inserted the data (using the statement below) into the table and it worked.
insert into DepartmentYT
values
(1, 'IT'),
(2, 'Sales')
Related
Can we decrease a size of a column? Suppose there is table A having column size 10. After inserting the data in the table, I want to reduce the size of the column. Can we reduce it?
Create table A
(Emp varchar2(10));
Insert into A values ('Ana');
Alter table A modify (varchar2(5));
Yes you can. An error will be thrown if the existing values have a larger size than the new datatype. See below.
koen>create table things (name VARCHAR2(100));
Table THINGS created.
koen>insert into things(name) values ('Car');
1 row inserted.
koen>alter table things modify name VARCHAR2(5);
Table THINGS altered.
koen>alter table things modify name VARCHAR2(2);
Error starting at line : 1 in command -
alter table things modify name VARCHAR2(2)
Error report -
ORA-01441: cannot decrease column length because some value is too big
01441. 00000 - "cannot decrease column length because some value is too big"
*Cause:
*Action:
koen>
Given a TABLE mytable with a column of TEXT name containing VALUES 1, 2, 2b, 2c, 3. How do you select the maximum INT value in SQLite?
-- Does not work in SQLite
SELECT MAX(VAL(textcol)) FROM mytable;
Took me some time to find as I kept falling on instructions for other SQL syntaxes.
SELECT MAX(CAST(name AS INT)) FROM mytable;
SQLite uses CAST(expr AS type-name) similar to MySQL
I would like to run a query involving joining a table to a manually generated list but am stuck trying to generate the manual list. There is an example of what I am attempting to do below:
SELECT
*
FROM
('29/12/2014', '30/12/2014', '30/12/2014') dates
;
Ideally I would want my output to look like:
29/12/2014
30/12/2014
31/12/2014
What's your Teradata release?
In TD14 there's STRTOK_SPLIT_TO_TABLE:
SELECT *
FROM TABLE (STRTOK_SPLIT_TO_TABLE(1 -- any dummy value
,'29/12/2014,30/12/2014,30/12/2014' -- any delimited string
,',' -- delimiter
)
RETURNS (outkey INTEGER
,tokennum INTEGER
,token VARCHAR(20) CHARACTER SET UNICODE) -- modify to match the actual size
) AS d
You can easily put this in a Derived Table and then join to it.
inkey (here the dummy value 1) is a numeric or string column, usually a key. Can be used for joining back to the original row.
outkey is the same as inkey.
tokennum is the ordinal position of the token in the input string.
token is the extracted substring.
Try this:
select '29/12/2014'
union
select '30/12/2014'
union
...
It should work in Teradata as well as in MySql.
I added a new column to my table, so there are now 4 instead of 3, and am now getting the following error when do a parametric insert (looped):
table 'test' has 4 columns but 3 values were supplied
Does this mean that you have to code your query for EVERY column the table has (as opposed to just the columns you want populated) when doing inserts, and that SQLite won't just add a default value if a column is missing from the query?
My query is:
"INSERT OR IGNORE INTO test VALUES (NULL, #col2, #col3)"
And this is the code that controls what's inserted in the recursive lopp:
sqlStatement.clearParameters();
var _currentRow:Object = _dataArray.shift();
sqlStatement.parameters["#col2"] = _currentRow.val2;
sqlStatement.parameters["#col3"] = _currentRow.val3;
sqlStatement.execute();
Ideally, I'd like column 4 to be left blank, without having to code it into the query.
Thanks for taking a look.
If you're inserting less values than there are columns, you need to explicitly specify the columns you are inserting to. For example
INSERT INTO test(firstcolumn,secondcolumn) VALUES(1,2);
Those columns that are not specified will get the default value, or NULL if there is no default value.
I noticed the other day that you can write a test where there are more columns in the Actual table that in the Expected table and the test will still pass if the the data matches in the columns that exist in both.
Here is an example:
if exists(select * from INFORMATION_SCHEMA.ROUTINES where ROUTINE_SCHEMA='UnitTests_FirstTry' and ROUTINE_NAME='test_AssertEqualsTable_IgnoresExtraColumnsInActual')
begin
drop procedure UnitTests_FirstTry.test_AssertEqualsTable_IgnoresExtraColumnsInActual
end
go
create procedure UnitTests_FirstTry.test_AssertEqualsTable_IgnoresExtraColumnsInActual
as
begin
IF OBJECT_ID(N'tempdb..#Expected') > 0 DROP TABLE [#Expected];
IF OBJECT_ID(N'tempdb..#Actual') > 0 DROP TABLE [#Actual];
create table #expected( a int null) --, b int null, c varchar(10) null)
create table #actual(a int, x money null)
insert #expected (a) values (1)
insert #actual (a, x) values (1, 22.51)
--insert #expected (a, b, c) values (1,2,'test')
--insert #actual (a, x) values (1, 22.51)
exec tSQLt.AssertEqualsTable '#expected', '#actual'
end
go
exec tSQLt.Run 'UnitTests_FirstTry.test_AssertEqualsTable_IgnoresExtraColumnsInActual'
go
I noticed this when I removed some extra columns from the Expected table of a test that no longer needed those columns, but I forgot to remove the same columns from the Actual table and my test still passed, which to me was a bit off putting.
This only happens when the Actual table has more columns. If the expected has more columns an error is generated. Is this correct? Does anyone know what the reasoning is behind this behavior?
Although not particularly well documented in this respect, the AssertEqualsTable routine only looks at the data in the table - not that the columns are the same. To check whether the table structures are the same, use AssertResultSetsHaveSameMetaData. I wrote a bit about this in this
article.
You can of course run both in the same test, and the test will only pass if both checks pass.
I guess the reason for the split would be because there may be rare instances where you care about either the data or the metadata being consistent for your test, but not both.