Here is part of my query that is getting the error
WHEN D.ROLE_NAME LIKE '%' + B.Project_Phase + '%'
AND D.ROLE_NAME LIKE '%Clinical Consultant%'
THEN D.RESOURCE_NAME END AS "Clinical Consultant"
Am I missing some parenthesis? It works in SQL fine but can't get it to work in snowflake. Thanks for the help.
To concatenate string in Snowflake you need to use || operator instead of +:
CASE WHEN D.ROLE_NAME LIKE '%' || B.Project_Phase || '%'
AND D.ROLE_NAME LIKE '%Clinical Consultant%'
THEN D.RESOURCE_NAME END AS "Clinical Consultant"
When + is used then implicit conversion occurs and that is the reason of the error: Numeric value '%' is not recognized
Related
I have this query below that is working fine on MySql and Oracle but fail on SQLServer:
#Query("SELECT ca FROM ContextAccess ca " + "LEFT JOIN UserContextAccess uca on ca.id = uca.id " +
"LEFT JOIN RegularUserInfo rui on rui.user = uca.user " +
"WHERE ca.context = :context and (COALESCE(:roles, null) is null or ca.role in (:roles)) " +
"AND (:name is null or ca.accessType='GROUP' or CONCAT(rui.firstName,' ',rui.lastName) like CONCAT(:name,'%') " +
"or CONCAT(rui.lastName,' ',rui.firstName) like CONCAT(:name,'%'))")
I have this stacktrace:
com.microsoft.sqlserver.jdbc.SQLServerException: The data types varbinary and varchar are incompatible in the add operator.
at com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDatabaseError(SQLServerException.java:262)
at com.microsoft.sqlserver.jdbc.SQLServerStatement.getNextResult(SQLServerStatement.java:1624)
at com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement.doExecutePreparedStatement(SQLServerPreparedStatement.java:594)
at com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement$PrepStmtExecCmd.doExecute(SQLServerPreparedStatement.java:524)
at com.microsoft.sqlserver.jdbc.TDSCommand.execute(IOBuffer.java:7194)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.executeCommand(SQLServerConnection.java:2979)
at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeCommand(SQLServerStatement.java:248)
at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeStatement(SQLServerStatement.java:223)
at com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement.executeQuery(SQLServerPreparedStatement.java:446)
the problem come from CONCAT(:name,'%')
I can solve it by using '+' operator like this :name + '%' but after it's not working on Oracle
Do you have an idea to solve this problem ?
Thanks,
You can use CONCAT(:name,\"%\")
The double-quote character has to be escaped with a backslash in a Java string literal.
I am trying to add a sum of my forecast using a code
select
sum(cast(replace(replace(ZFREEGOOD, ',', ''), ' ', '') as decimal(22,8)))
from
TEMP_GBR_History_1611
I keep getting an error
Error converting data type nvarchar to numeric.
I used a case statement to figure out which rows failed. These are some of them
Would be of great help to get a solution
You're not handling the blank case, this works with test data:
select sum(cast(case when replace(replace(ZFREEGOOD,',',''),' ','') = '' then '0' else replace(replace(ZFREEGOOD,',',''),' ','') end as decimal(22,8))) from TEMP_GBR_History_1611
One option is to use try_convert(money,...) It tends to be a little more forgiving.
Example
Select AsMoney = try_convert(money,' 27,300') -- works!
,AsInt = try_convert(int,' 27,300')
,AsDec = try_convert(decimal(10,2),' 27,300')
,AsFloat = try_convert(float,' 27,300')
Returns
AsMoney AsInt AsDec AsFloat
27300.00 NULL NULL NULL
I've been tasked with fixing some SQL code that doesn't work. The query reads from a view against a predicate. The query right now looks like so.
SELECT TOP (100) Beginn
FROM V_LLAMA_Seminare
//Removal of the following line makes the query successful, keeping it breaks it
where Beginn > (select cast (getdate() as smalldatetime))
order by Beginn desc
When I run the above query, I am greeted with the following error.
Msg 295, Level 16, State 3, Line 1
Conversion failed when converting character string to smalldatetime data type.
I decided to remove the WHERE clause, and now it runs returning 100 rows.
At first, I thought that behind the scenes, SQL Server was somehow including my predicate when bringing back the View . But then I investigated how the View was being created, especially the Beginn field, and at no point does it return a String.
Long story short, the column that becomes the Beginn field is a BIGINT timestamp like 201604201369.... The original user transforms this BIGINT to a smalldatetime using the following magic.
....
CASE WHEN ma.datum_dt = 0
THEN null
ELSE CONVERT(smalldatetime, SUBSTRING(CAST(ma.datum_dt AS varchar(max)),0,5) + '-' +
SUBSTRING(CAST(ma.datum_dt AS varchar(max)),5,2) + '-' +
SUBSTRING(CAST(ma.datum_dt AS varchar(max)),7,2) + ' ' +
SUBSTRING(CAST(ma.datum_dt AS varchar(max)),9,2) +':'+
SUBSTRING(CAST(ma.datum_dt AS varchar(max)),11,2) +':' +
RIGHT(CAST(ma.datum_dt AS varchar(max)),2)) END AS Beginn
...
My last attempt at finding the problem was to query the view and run the function ISDATE over the Beginn column and see if it returned a 0 which it never did.
So my question is two fold, "Why does a predicate break something" and two "Where on earth is this string error coming from when the Beginn value is being formed from a BIGINT".
Any help is greatly appreciated.
This problem is culture related...
Try this and then change the first SET LANGUAGE to GERMAN
SET LANGUAGE ENGLISH;
DECLARE #bi BIGINT=20160428001600;
SELECT CASE WHEN #bi = 0
THEN null
ELSE CONVERT(datetime, SUBSTRING(CAST(#bi AS varchar(max)),0,5) + '-' +
SUBSTRING(CAST(#bi AS varchar(max)),5,2) + '-' +
SUBSTRING(CAST(#bi AS varchar(max)),7,2) + ' ' +
SUBSTRING(CAST(#bi AS varchar(max)),9,2) +':'+
SUBSTRING(CAST(#bi AS varchar(max)),11,2) +':' +
RIGHT(CAST(#bi AS varchar(max)),2)) END AS Beginn
It is a very bad habit to think, that date values look the same everywhere (Oh no, my small application will never go international ...)
Try to stick to culture independent formats like ODBC or ISO
EDIT
A very easy solution for you actually was to replace the blank with a "T"
SUBSTRING(CAST(ma.datum_dt AS varchar(max)),7,2) + 'T' +
Then it's ISO 8601 and will convert...
The solution was found after looking through #Shnugo's comment. When I took my query which contained the Bigint->Datetime conversion logic, and put it into a CTE with "TOP 100000000" to avoid any implicit conversion actions, my query worked. Here is what my view looks like now with some unimportant parts omitted.
---Important part---
CREATE VIEW [dbo].[V_SomeView] AS
WITH CTE AS (
SELECT TOP 1000000000 ma.id AS MA_ID,
---Important part---
vko.extkey AS ID_VKO,
vko.text AS Verkaufsorganisation,
fi.f7000 AS MDM_Nr,
vf.f7105 AS SAPKdnr,
CASE WHEN ma.datum_dt = 0 --Conversion logic
CASE WHEN ma.endedatum_dt = 0 --Conversion logic
CONVERT(NVARCHAR(MAX),art.text) AS Art,
.....
FROM [ucrm].[dbo].[CRM_MA] ma,
[ucrm].[dbo].[CRM_fi] fi,
[ucrm].[dbo].[CRM_vf] vf,
[ucrm].[dbo].[CRM_ka] vko,
[ucrm].[dbo].[CRM_ka] art,
[ucrm].[dbo].[CRM_ka] kat
where ma.loskz = 0
and fi.loskz = 0
and vf.loskz = 0
and fi.F7029 = 0
and vf.F7023 = 0
...
GROUP BY ma.id,
vko.extkey,
vko.text,
fi.f7000 ,
vf.f7105,
ma.datum_dt,
ma.endedatum_dt,
....
)
select * FROM CTE;
Here is the section of code, I am using ' ' blah ' ' to escape single quotes but I guess its not working:
declare
my_func varchar2(20) :='test_func';
begin
execute immediate 'insert into TABLE_TEST (OUTPUT) select ' || my_func || ' from dual where TABLE_TEST.FUNCTION_NAME like ' 'VALIDATION1_%' ' ';
end;
I am getting the following error:
PLS-00103: Encountered the symbol "VALIDATION1_%" when expecting one of the following:
& = - + ; < / > at in is mod remainder not rem return
returning <an exponent (**)> <> or != or ~= >= <= <> and or
like like2 like4 likec between into using || bulk member
submultiset
The symbol "* was inserted before "VALIDATION1_%" to continue.
It looks like you are trying to escape the single quote with another single quote (which is good), but there is an extra space in between the two. That has to go.
Change
' from dual where TABLE_TEST.FUNCTION_NAME like ' 'VALIDATION1_%' ' '
to
' from dual where TABLE_TEST.FUNCTION_NAME like ''VALIDATION1_%'' '
In cases like this it's much simpler to use the new q syntax for literal strings, e.g.:
execute immediate 'insert into TABLE_TEST (OUTPUT) select ' || my_func ||
q[' from dual where TABLE_TEST.FUNCTION_NAME like 'VALIDATION1_%' ]';
I have the following CLR function:
[Microsoft.SqlServer.Server.SqlFunction]
public static SqlString PrintText(SqlString text)
{
// Put your code here
return new SqlString(text.Value);
}
And I want to get an enter symbol when passing '\r\n'
to it. But insteat I get '\r\n'
Could you please tell me what's wrong with this code.
Thank you.
In T-SQL you don't write a line break as \r\n. Instead you just use a line break:
'this
is a
string
in SQL
with
line breaks'
If you pass a string with \r\n to the C# code, nothing magical happens, it doesn't automatically get converted. The backslash character is just a character like any other. It's when you use the backslash in a literal string in the code that the compiler uses it as an escape code, and puts the control characters in the actual string.
You could always:
return new SqlString(text.Value.Replace("\\r\\n", "\r\n"));
From the SQL side, you could insert char(13) + char(10) into your T-SQL literals like so:
DECLARE #text varchar(100)
SET #test = 'this' + char(13) + char(10)
+ 'is a' + char(13) + char(10)
+ 'string' + char(13) + char(10)
+ 'in SQL' + char(13) + char(10)
+ 'with' + char(13) + char(10)
+ 'line breaks'
Though this works, it is much more verbose than Guffa's answer.
However, this technique can also be used to insert any character of the default code page into a string. The Function CHAR(int) accepts any integer between 0 and 255. Values outside that range cause it to return null. The function NCHAR(int) accepts values up to 65535 and inserts the corresponding unicode characters into a unicode string. Functions ASCII(char) and UNICODE(nchar) perform the inverse operations.