At work I saw I saw a SQL query in Teradata that had the following:
CASE WHEN (sp_ce / ‘0000001000000000’XI8) MOD 2 = 1 THEN ‘Y’ ELSE ‘N’ END AS res_p
What is the meaning of XI8? What is it doing to the number string?
Also when I tried to run this in Big Query it’s not supported, it errors out with
Syntax error: Unexpected identifier \XI8\
How would I write that case statement in big query?
Using MOD on big query without the numbers as a string and without the XI8 yields different results.
Thank you
Related
I have a data source like following
If I ran the following sql query it removes all the records with "Seg Type" MOD and ignores the Fnn range given.
select * from NpsoQueue
where SegmentType not in ('MOD')
and Fnn not between 0888452158 and 0888452158
I want the query to consider both conditions. So, if I ran the query it should remove only the first record
The logic in your where clause is incorrect
Use
select * from NpsoQueue
where NOT (
SegmentType = 'MOD'
and Fnn between '0888452158' and '0888452158'
)
Also, a number with a leading zero is a string literal so you need to put single quotes around it to preserve the leading zero and stop implicit casts happening
As mentioned by #TriV you could also use OR. These are fundamental boolean logic concepts, i.e. not related to SQL Server or databases
I'm having some trouble understanding WHY a select statement isn't working in a query I'm making.
I've got the SELECT and FROM lines functioning. With just those, ALL results from my selected table are displayed - 517 or so
What I want to do is display results based on a pattern using LIKE - What I have so far
SELECT *
FROM Tbl_ServiceRequestMatrix
WHERE Tbl_ServiceRequestMatrix.[Application/Form] LIKE 'P%';
This returns 0 results - despite the fact that the column selected DOES have entries that start with 'P'
I also tried utilising brackets, see if that was the issue - still displays 0 results:
SELECT *
FROM Tbl_ServiceRequestMatrix
WHERE ((Tbl_ServiceRequestMatrix.[Application/Form])='p%');
Can any one help me understand why my WHERE ** LIKE statement is causing 0 results to be displayed?
The wildcard character in MS Access is (by default) * instead of %:
WHERE Tbl_ServiceRequestMatrix.[Application/Form] LIKE "P*"
LIKE Statement has different parameters in different sql languages.
In MS Access you need * Instead of % in LIKE Statement.
following situation:
a column xy is defined as varchar(25). In a view (SQL Server Mgmt Studio 2008) I filtered all values with letters (-> is not like '%[A-Z]%') and converted it to int (cast(xy as int)).
If I now try to make comprisons with that column (e.g. where xy < 1000), I'm getting a conversion error. And the message contains a value that should have been filtered with "is not like '%[A-Z]%'". Whats wrong??
thanks for help in advance...
this works (it folters out for example value 'G8111'):
SELECT unid
FROM CD_UNITS AS a INNER JOIN DEF_STATION AS b ON a.STATION = b.STATION
WHERE (b.CURENT = 'T') and UNID like '%[A-Z]%'
but when i put that in a view, an make select on it:
select * from my_view where xy < 3000
system says 'Conversion failed when converting the varchar value 'G8111' to data type int.' but 'G8111' should be filtered out in query above...
The optimizer does crazy things at times, so despite the fact that an "inner" filter1 "should" protect you, the optimizer may still push the conversion lower down than the filter and cause such errors.
The only semi-documented place where it will not do this is within a CASE expression:
The CASE statement(sic) evaluates its conditions sequentially and stops with the first condition whose condition is satisfied. In some situations, an expression is evaluated before a CASE statement receives the results of the expression as its input.
...
You should only depend on order of evaluation of the WHEN conditions for scalar expressions (including non-correlated sub-queries that return scalars), not for aggregate expressions
So the only way that should currently work would be:
CASE WHEN xy NOT LIKE '%[^0-9]%' THEN CONVERT(int,xy) END < 1000
This also uses a double-negative with LIKE to ensure that it only attempts the conversion when the value only contains digits.
1Whether this be in a subquery, a CTE, a View, or even just considering the logical processing order of SELECT and WHERE clauses. Within a single query, the optimizer can and will push conversion operations past filters.
In most RDBMS:es, this work:
select (5 > 3)
and evaluates to true. It doesn't work in MS Transact SQL and the only workaround I've found is to write:
select case when 5 > 3 then 1 else 0 end
Which kind of sucks because it is much more verbose. Is there a better way to write the above kind of checks?
If the problem is arithmetic comparison:
select (5 - 3)
Then at the application level test for < or = or > 0.
You could write it as a scalar-valued function, but it will be very slow on large datasets.
If your program often requires such case constructs you could create your set of functions that will have user functions like Bool_IsGreater(left, right) that will return you your desired 0 or 1.
SQL Server doesn't support boolean value type anyway even for basic column use.
If you will need performance and those 5 and 3 values come naturally from some select query you might want to create a new column and set its value to 1 or 0 by trigger or something, which could help with performance.
I am trying to get some percentage data from a stored procedure using code similar to the line below. Obviously this is going to cause a (Divide by zero error encountered) problem when base.[XXX_DataSetB] returns 0 which may happen some of the time.
Does anyone know how i can deal with this in the most efficient manner?
Note: There would be about 20+ lines looking like the one below...
cast((base.[XXX_DataSetB] - base.[XXX_DataSetA]) as decimal) /
base.[XXX_DataSetB] as [XXX_Percentage]
I guess it depends on what behaviour you expect when XXX_DataSetB is zero.
If you don't want any rows returned that might cause an error, you can easily filter out those rows by adding where XXX_DataSetB <> 0 to your query.
If you would like problem rows to be NULL then you could use a case statement, or something like this:
cast(([XXX_DataSetB] - [XXX_DataSetA]) as decimal) / nullif([XXX_DataSetB], 0)
I'd force the average to null by making the bottom term null instead of zero:
cast((base.[XXX_DataSetB] - base.[XXX_DataSetA]) as decimal)
/ case when base.[XXX_DataSetB] = 0 then null
else base.[XXX_DataSetB] end as [XXX_Percentage]