I have a CSV I'm importing into our database. One of the "columns" contains data that should be an INT but some rows have numbers that only fall in the BIGINT range (because they're test data from one of our partners). We store INT internally and have no desire to change.
I want to safely downcast from BIGINT to INT. By safely, I mean no errors should be raised if an arithmetic overflow happens. If the cast/conversion succeeds, I want my script to go on. If it fails, I want it to short-circuit. I can't seem to figure out the proper syntax. This is what I've got:
DECLARE #UserIDBigInt BIGINT = 9723021913; -- actually provided by query param
--Setting within the INT range successfully converts
--SET #UserIDBigInt = 5;
DECLARE #UserID INT = CONVERT(INT, #UserIDBigInt);
--DECLARE #UserID INT = CAST(#UserIDBigInt AS INT);
SELECT #UserIDBigInt
SELECT #UserID
IF #UserID IS NOT NULL BEGIN
SELECT 'Handle it as reliable data'
END
I've thought about comparing #UserIDBigInt to the valid range of an INT (-2^31 (-2,147,483,648) to 2^31-1 (2,147,483,647)), but I really don't like that approach. That's my fallback. I was hoping for some language constructs or built-in functions I could use. If I absolutely have to compare to the valid range, are there at least some built-in constants (like C#'s int.MinValue & int.MaxValue)?
EDIT: Corrected typo.
Add these to your script:
SET ARITHABORT OFF;
SET ARITHIGNORE ON;
This will convert any overflow values to NULL.
More info here: http://msdn.microsoft.com/en-us/library/ms184341.aspx
Cast your bigint to varbinary, then store the lower half to #UserID and check the upper half:
if the upper half is all 0's and the lower half represents a non-negative value, #UserID then contains the correct int value;
if the upper half is all 1's and #UserID is negative, it's all right too;
otherwise there's an arithmetic overflow.
Here's an implementation:
DECLARE #UserIDBigInt BIGINT = 9723021913;
DECLARE #UserID INT, #HighInt INT;
WITH v AS (SELECT CAST(#UserIDBigInt AS varbinary) AS bin)
SELECT
#HighInt = SUBSTRING(bin, 1, 4),
#UserID = SUBSTRING(bin, 5, 4)
FROM v;
IF (#HighInt = 0 AND #UserID >= 0 OR #HighInt = -1 AND #UserID < 0) BEGIN
SELECT 'Handle it as reliable data'
END
I'm not sure this is the best answer but it is one I came up with earlier on my own. It is possible to catch the exception/error and gracefully continue execution.
Example:
DECLARE #UserIDBigInt BIGINT = 9723021913;
DECLARE #UserID INT;
BEGIN TRY
SET #UserID = #UserIDBigInt;
END TRY BEGIN CATCH
END CATCH
IF #UserID IS NULL BEGIN
SELECT 'Handle it as unreliable data'
RETURN
END
SELECT 'Handle it as reliable data'
You could also convert the value to a string, trim it to length and convert to int. not the best way, but a safe easy way for sure
Related
I have been working in the SQL language for 1 month. That's why I may not understand things. But I always get an error when creating these functions. I wrote the codes down there. The error message is as follows:
Only one expression can be specified in the select list when
the subquery is not introduced with EXISTS.
CREATE FUNCTION deneme(
#ID int
)
RETURNS nvarchar(max)
AS
BEGIN
DECLARE #value nvarchar(max)
SET #value = (
SELECT * FROM information
WHERE #ID = Person_id
)
RETURN #value
END
You cannot assign all columns values into one variable like that, and since you're passing an ID of the person and you want your function to returns the info of that person
CREATE FUNCTION dbo.deneme
(
#ID int
)
RETURNS NVARCHAR(300)
AS
BEGIN
DECLARE #Value NVARCHAR(300) = N'';
SELECT #Value = CONCAT(I.FirstName, N' ', I.LastName)
FROM Information I
WHERE I.PersonId = #ID;
RETURN #Value;
END
As others have pointed out you are trying to place multiple columns/fields in a single column/field.
#ID is a single column. "Select *" is presumably returning more than a single column or else it wouldn't be much help!
In order to change this and make it work as you are trying here, you would need to concat the columns you are trying to return. This is almost surely not the best way to accomplish this but sometimes concating names (for example) is fine.
The other issue you may be running into is even if you changed this to "Select ID" but still have errors it may be because the query returns more than one row matching that criteria. You can work around this (it is a work around most of the time) by limiting the number of rows returned with "TOP 1". But be careful as this may not return the information you want. You can use an order by statement to help ensure it is the correct information (such as order by Time_entered).
The code below with "TOP 1" and concatenating multiple columns (and casting as the same type) will always work.
Again, these are not Best Practices and shouldn't be used to sanitize data in production... but it does show you why you are getting these errors and how to prevent them.
CREATE FUNCTION deneme(
#ID int
)
RETURNS nvarchar(max)
AS
BEGIN
DECLARE #value nvarchar(max)
SET #value = (
SELECT TOP 1 cast(First_name as nvarchar) + N' ' + cast(Last_name as nvarchar) FROM information
WHERE #ID = Person_id
Order by Time_entered desc
)
RETURN #value
END
I have a stored procedure that I have created that for right now I am not touching a database.
Pseudo code
CREATE PROCEDURE [dbo].[CustomerKeyChecker]
#ldccode VARCHAR(12)
AS
#result int = 0
BEGIN
DECLARE #listofCodes varchar(200)
SET #listofCodes = 'CLP, UIC, NSTAR, NSTARB, NSTARC, PSNH'
-- So lets say that the passed in #ldccode is "CLP" , well then I went to
-- set a #result = 1
END
What is the a decent way to do a substring to search for these codes inside list?
Pseudo code:
substring(#lcdcode, #listOfCodes) ?
Again, for now this is nothing to do with the database, and I understand that someone would say "why even pass this data to sql" ... there will be sql tables added in later is why ...
You may notice that we add a space to the begining and comma to the end of each variable. This is to prevent false positives i.e. STAR. You may also notice SIGN(), this will return 1 if a positive number, 0 if not found.
Declare #ldccode VARCHAR(12) = 'CLP'
Declare #result int = 0
declare #listofCodes varchar(200)
SET #listofCodes = 'CLP, UIC, NSTAR, NSTARB, NSTARC, PSNH'
Select #result=sign(charindex(' '+#ldccode+',',' '+#listofCodes+','))
Returns
1
I'm trying search in Arabic text in SQL Server and need to ignore the Arabic diacritics.
So I'm using Arabic_100_CI_AI collation. but it's not work.
For example for the below query I must get 1, but it has no result!
select 1
where (N'مُحَمَّد' Collate Arabic_100_CI_AI) = (N'محمّد' Collate Arabic_100_CI_AI)
What is the problem and how can I perform diacritics insensitive comparison in Arabic text?
It seems AI flag is NOT working for Arabic. You can build your own Unicode Normalization function.
ALTER FUNCTION [dbo].[NormalizeUnicode]
(
-- Add the parameters for the function here
#unicodeWord nvarchar(max)
)
RETURNS nvarchar(max)
AS
BEGIN
-- Declare the return variable here
DECLARE #Result nvarchar(max)
-- Add the T-SQL statements to compute the return value here
declare #l int;
declare #i int;
SET #l = len(#unicodeWord + '-') - 1
SET #i = 1;
SET #Result = '';
WHILE (#i <= #l)
BEGIN
DECLARE #c nvarchar(1);
SET #c = SUBSTRING(#unicodeWord, #i, 1);
-- 0x064B to 0x65F, 0x0670 are Combining Characters
-- You may need to perform tests for this character range
IF NOT (unicode(#c) BETWEEN 0x064B AND 0x065F or unicode(#c) = 0x0670)
SET #Result = #Result + #c;
SET #i = #i + 1;
END
-- Return the result of the function
RETURN #Result
END
Following test should work correctly,
select 1
where dbo.NormalizeUnicode(N'بِسمِ اللہِ الرَّحمٰنِ الرَّحیم') = dbo.NormalizeUnicode(N'بسم اللہ الرحمن الرحیم');
Notes:
You may experience slow performance with this solution
The character range I've used in the function is NOT thoroughly tested.
For a complete reference on Arabic Unicode Character Set, see this document http://www.unicode.org/charts/PDF/U0600.pdf
Your use of collation is correct but if you carefully see the two Arabic words in your query (highlighted bold) they are completely different even though their meaning same and hence you are not getting the result (since comparison is failing)
N'مُحَمَّد' and N'محمّد'
I am pretty sure, if you try to find out their unicode value using unicode() function; their result will be different.
If you try the below query, it will succeed
select 1
where N'مُحَمَّد' Collate Arabic_100_CI_AI like '%%'
See this post for a better explanation
Treating certain Arabic characters as identical
I need to do some math with SQL Server GUIDs in a trigger and I'm having difficulty figuring out how to convert a uniqueidentifier to a numeric(38,0).
One potential problem: my understand is that both of these datatypes are 16-byte "integers". If I'm wrong here, please correct me.
Otherwise, how would I go about this conversion? I've tried CAST and CONVERT and keep getting Explicit conversion from data type uniqueidentifier to numeric is not allowed. as an error message whenever I try. I'd really like to not have to parse each character and do hex math in a UDF to do this.
Is this possible?
Here's my script to repro this real quick:
DECLARE #guid uniqueidentifier
SET #guid = NEWID()
DECLARE #a numeric(38,0)
SET #a = 2
PRINT CAST(#guid AS numeric(38,0)) -- fails
PRINT #guid / #a -- also fails
Unfortunately, I haven't stumbled on a conversion from a hexadecimal value in a VARCHAR to a NUMERIC short of looping through one digit at a time.
declare #GUID as UniqueIdentifier = NewId()
declare #Binary as VarBinary(64) = #GUID
declare #String as VarChar(64) = Convert( VarChar(64), #Binary, 2 )
select #GUID as 'GUID', #Binary as 'Binary', #String as 'String'
This is a follow up to my previous question, in t-sql
SELECT SCOPE_IDENTITY()
returns a BIGINT, I did the following to get it to return an INT:
DECLARE #X INT
INSERT ...
SELECT #X = SCOPE_IDENTITY()
-- if i don't include the line below, it will return a BIGINT
SELECT #X
Why does it return a BIGINT unless I do SELECT #X at the end?
p.s. turns out
SELECT #X = SCOPE_IDENTITY()
doesn't return anything, it just sets #x
The statement
SELECT #X = SCOPE_IDENTITY()
is an assignment statement. As in most programming languages, an assignment statement is executed by first evaluating the right hand side. In this case the right hand side evaluates to a bigint. When the value of #X gets the resulting bigint, there is an implicit type conversion, because #X is a different type (int) than the value it's receiving.
SQL is a typed language, and the type of an expression (such as SCOPE_IDENTITY() here) depends on the expression, not on what happens to the expression's value after evaluation.
Analogy:
DECLARE #i INT;
SET #i = 3.2 + 0.2;
You wouldn't suggest that 3.2 + 0.2 is an integer, would you? It's 3.4, a decimal. Only because of the assignment is there an implicit conversion to INT.
There's no magic in most programming languages.
SELECT SCOPE_IDENTITY()
returns a BIGINT as you have seen
SELECT #X = SCOPE_IDENTITY()
returns BIGINT and casts it into INT variable #X
So you are returning BIGINT SCOPE_IDENTITY and also concurrently casting it to INT and setting that result to #X.
Returning #X returns the INT result.
Just some interesting reading on the subject.
SQL Server 7.0 Books Online also
stated: "It is recommended that SET
#local_variable be used for variable
assignment rather than SELECT
#local_variable."