I have written a query in my stoted procedure, something like,
INSERT INTO Table1
(UniqueStr, Col1, Col2)
SELECT UniqueStr, Col1, Col2
FROM Table2
WHERE ...
It gives me error:
string or binary data would be truncated.
Here are the statistics.
Table1.UniqueStr is VARCHAR(11)
Table2.UniqueStr is VARCHAR(20)
Table2 has records having UniqueStr values of 11 characters and 15 characters.
The where clause of query is written in such a way that SELECT statement will never return records having UniqueStr length greater than 11.
The first weird scenario is - even though SELECT statement returns nothing (when run separately), it gives truncation error when run along with INSERT (i.e. INSERT...SELECT).
Second weird scenario is - it gives error only in Production environment. It gave no error in UAT environment. In Production environment, it ran fine for 1 day.
can anyone tell me what could be the issue?
Note: I fixed this error using SUBSTRING function but I could not find out the reason why SQL server gives this error?
Related
I'm using SQL developer and I'm getting an error I don't fully understand.
Due to data privacy, I cannot share the real query, but the question is fairly simple.
I have a query to obtain table T (which works if ran alone) and I want to filter a Y/N flag so I have the following query:
select * from T where flag ='Y'
While this query works, I want the observations which do not fullfil the condition but neither of the following queries works:
select * from T where flag <>'Y'
select * from T where flag ='N'
*I get the following error:
01722. 00000 - "invalid number"
*Cause: The specified number was invalid.
Action: Specify a valid number .
Vendor code 1722
I tried to export the table to analyze it on another language, but I still get the same error.
Can anyone help?
As you confirmed T in your example is not a table, your error simply seems to be caused by a conversion error somewhere on 1 or several records WHERE flag <> 'Y'. This is why the query works with flag = 'Y' but not with your other conditions.
Minimal case to reproduce would be something like:
CREATE TABLE MyTable (
Field VARCHAR(10),
Flag VARCHAR(1)
);
CREATE VIEW T AS SELECT to_number(Field), Flag FROM MyTable;
INSERT INTO MyTable VALUES ('1', 'Y'); /* OK */
INSERT INTO MyTable VALUES ('No way', 'N'); /* Fails */
In your case, the error may not be caused by a call to to_number but this is the best clue I can give given the limited information you provide. It might not be a call to a function at all but the result of a calculation using operators only.
You simply need to make sure the fields can be converted/used in a calculation before you actually attempt to do so (CASE WHEN ... THEN ... ELSE NULL for instance).
We have a statement in some legacy SQL Server 2005 code like
insert into myTable
select distinct
wherefield1,
wherefield2,
anotherfield,
convert(numeric(10,2), varcharfield1),
convert(numeric(10,2), varcharfield2),
convert(numeric(10,2), varcharfield3),
convert(datetime, varcharfield4),
otherfields
from myStagingTable
where insertflag='true'
and wherefield1 = #wherevalue1
and wherefield2 = #wherevalue2
Earlier in the code, a variable is set to determine whether varcharfield1 or varcharfield2 is null, and the insert is programmed to execute as long as one of them is not null.
We know that if varcharfield1, varcharfield2, or varcharfield3 is a nonnumeric character string, an exception will be thrown and the insert will not occur. But I am perplexed by the behavior when one of these variables is null, as it often is. Actually, it is always the case that one of these values is null. But it seems that the insertion does take place. It looks like the legacy code relies on this to prevent only insertion of nonnumeric character data, while allowing insertion of null or empty values (in an earlier step, all empty strings in these fields of myStagingTable are replaced with null values).
This has been running on a Production SQL Server 2005 instance with all default settings for a number of years. Is this behavior we can rely on if we upgrade to a newer version of SQL Server?
Thanks,
Rebeccah
conversion of NULL to anything is still NULL. If the column allows NULL, that's what you'll get. If the column is not nullable, it will fail.
You can see this yourself without even doing an INSERT. Just run this:
SELECT CONVERT(numeric(10,2), NULL)
and note how it produces a NULL result. Then run this:
SELECT CONVERT(numeric(10,2), 'x')
and note how it throws an error message instead of returning anything.
For a 10 minute period yesterday, a SQL stored procedure kept throwing the error "string or binary data would be truncated" when it was executed via my webserver. However, when I ran the exact same SQL command via Microsost SQL Server Management Studio there was no error.
In the SP there is only one insert statement; here's an abstraction of it:
DECLARE #TempTable table (Row1 varchar(25), Row2 varchar(4), Row3 int)
INSERT INTO #TempTable (Row1,Row2,Row3)
SELECT DISTINCT
A.Value
,RIGHT(A.Text,4)
,CAST(ISNULL(A.Thing,'0') as int)
FROM ActivityTable A
In the database Activity table, each of those rows is defined as varchar(25) though Thing is always used for integers (stored as varchar, yes it's stupid). On the face of it I can't see how any of those could exceed the insert column's size.
I tried commenting them out one-by-one, inserting an empty string instead. First I replaced A.Value with '' and refreshed the webpage that executes the procedure; there was no error. I assumed this was the problem column so I put it back to the original value, assuming this would bring back the error. Except it didn't, and since then the error hasn't reoccurred.
This SP has run without issues for months, and only broke for those 10 minutes yesterday. Last week I raised the compatibility level on my SQL server from 100 to 130, so I'm assuming that must be somehow connected. But it also seems to have been affected by me altering the procedure, in addition to being time-specific and user-specific.
1) In code you are declaring table #TempTable and inserting into #Temp
2) A.Value in some cases is longer then 25chars. Try to use LEFT(A.Value,25) instead. Or extend the column size.
I have 2 queries, which takes data dynamically.
Select cid from table1 where cNumber={{custNbr}}
Here {{custNbr}} comes from a .txt file.
update table2 set status='A' where customer_id=NVL({{cid}},0000)
Here {{customer_id}} comes from output of step 1.
Issue: When step 1 returns NULL, it actually returns an empty string ''. As a result, Step 2 translates to -
update table2 set status='A' where customer_id=NVL(,0000)
This throws an error java.sql.SQLSyntaxErrorException: ORA-00936: missing expression
How do I rewrite the queries to make them work.
In your case, it's probably sufficient to provide a fallback for the result of the first query:
Select nvl(cid, -1) as cid
from table1
where cNumber={{custNbr}}
This assumes that -1 does not appear as a customer ID in table2. Therefore, the UPDATE will be syntactically valid, but it will update zero rows.
CAVEAT
However, I'd be strongly suspicious of a tool that cannot handle NULL values as input to Database queries. You might want to contact the DevTest support regarding this.
I have a query like :
select * from table where varchar_column=Numeric_value
that is fine until I run an insert script. After the new data is inserted, I must use this query:
select * from table where varchar_column='Numeric_value'
Can inserting a certain kind of data cause it to no longer implicitly convert?
After the insert script, the error is Data conversion fails OLEDB Status = 2
And the second query does work
I'm not certain of this... the first may be doing an implicit conversion of the varchar_column to a numeric value. Not the other way around. But when you insert values into that column that's no longer convertable, it fails. However, with the second, you're doing a varchar to varchar comparison and all is right again with the world. My guess.