I might be missing something easy here, as someone relatively new to SQL, I am trying the following query:
DECLARE #uidd VARCHAR
SELECT #uidd = UID
FROM PRODUCTOBJECT WHERE EMAIL='abc#gmail.com';
SELECT ProductID FROM PRODUCTUIDMAPPING WHERE UID= #uidd;
And it is returning zero rows. What's puzzling is that if do not use variables and run both selects separately, I do get the right row back.
SELECT UID FROM TABLEA WHERE EMAIL='abc#gmail.com';
returns the UID, and then
SELECT ProductID FROM TABLEB WHERE UID='123456';
will return the ProductID value, where '123456' would be the value returned from the first query.
The problem is when combined together, using the variable for some reason it seems #uidd is not being set. Any reason why ?
I am running this on SQL Server 2008.
Presumably, uuid is longer than one character. Never use character types in SQL Server without a length. The default varies by context and may not be correct.
So, this should work:
DECLARE #uidd VARCHAR(255);
SELECT #uidd = UID
FROM PRODUCTOBJECT
WHERE EMAIL='abc#gmail.com';
SELECT ProductID
FROM PRODUCTUIDMAPPING
WHERE UID= #uidd;
Related
Please disregard the obvious problems with the manipulation of data in the where clause. I know! I'm working on it. While working on it, though, I discovered that this query runs:
SELECT *
FROM PatientDistribution
WHERE InvoiceNumber LIKE'PEX%'
AND ISNUMERIC(CheckNumber) = 1
AND CONVERT(BIGINT,CheckNumber) <> TransactionId
And this one does not:
SELECT *
FROM PatientDistribution
WHERE InvoiceNumber LIKE'PEX%'
AND CONVERT(BIGINT,CheckNumber) <> TransactionId
AND ISNUMERIC(CheckNumber) = 1
The only difference between the two queries is the order of items in the WHERE clause. I was under the impression that the SQL Server query optimizer would take the worry out of me having to worry about that.
The error returned is: Error converting data type varchar to bigint.
You are right, the order of the conditions shouldn't matter.
If AND ISNUMERIC(CheckNumber) = 1 is checked first and non-matching rows thus dismissed, then AND CONVERT(BIGINT,CheckNumber) <> TransactionId will work (for exceptions see scsimon's answer).
If AND CONVERT(BIGINT,CheckNumber) <> TransactionId is processed before AND ISNUMERIC(CheckNumber) = 1 then you may get an error.
That your first query worked and the second not was a matter of luck. It could just as well have been vice versa.
You can force one condition to be executed before the other:
SELECT *
FROM
(
SELECT *
FROM PatientDistribution
WHERE InvoiceNumber LIKE 'PEX%'
AND ISNUMERIC(CheckNumber) = 1
) num_only
WHERE CONVERT(BIGINT,CheckNumber) <> TransactionId;
You just got lucky that the first one worked, since you are correct that the order of what you list in the where clause does not matter. SQL is a declarative language meaning that you are telling the engine what should happen, not how. So your queries weren't executed with the same query plan I would suspect. Granted, you can affect what the optimizer does to a certain extent. You'll also notice this type of issue when using a CTE. For example:
declare #table table(columnName varchar(64))
insert into #table
values
('1')
,('1e4')
;with cte as(
select columnName
from #table
where isnumeric(columnName) = 1)
select
cast(columnName as decimal(32,16))
from cte
The above snippet you would assume that the second statement is ran on the results / subset from the CTE statement. However, you can't ensure this will happen and you could still get a type/conversion error on the second statement.
More importantly, you should know that ISNUMERIC() is largely misused. People often think that if it returns 1 then it could be converted to a decimal or int. But this isn't the case. It just checks that it's a valid numeric type. For example:
select
isnumeric('1e4')
,isnumeric('$')
,isnumeric('1,123,456')
As you can see, these evaluate to true, but would fail the conversion you put in your post.
Side note, your indexes are likely the reason why the first actually didn't error our.
I am working on a query that will check the temp table if there is a record that do not exist on the main table. My query looks like this
SELECT * FROM [Telemarketing].[dbo].[PDCampaignBatch_temp]
WHERE [StartDateTime] NOT IN (SELECT [StartDateTime] FROM [Telemarketing].[dbo].PDCampaignBatch GROUP BY [StartDateTime])
but the problem is it does not display this row
even if that data does not exist in my main table. What seems to be the problem?
NOT IN has strange semantics. If any values in the subquery are NULL, then the query returns no rows at all. For this reason, I strongly recommend using NOT EXISTS instead:
SELECT t.*
FROM [Telemarketing].[dbo].[PDCampaignBatch_temp] t
WHERE NOT EXISTS (SELECT 1
FROM [Telemarketing].[dbo].PDCampaignBatch cb
WHERE t.StartDateTime = cb.StartDateTime
);
If the set is evaluated by the SQL NOT IN condition contains any values that are null, then the outer query here will return an empty set, even if there are many [StartDateTime]s that match [StartDateTime]s in the PDCampaignBatch table.
To avoid such issue,
SELECT *
FROM [Telemarketing].[dbo].[PDCampaignBatch_temp]
WHERE [StartDateTime] NOT IN (
SELECT DISTINCT [StartDateTime]
FROM [Telemarketing].[dbo].PDCampaignBatch
WHERE [StartDateTime] IS NOT NULL
);
Let's say PDCampaignBatch_temp and PDCampaignBatch happen to have the same structure (same columns in the same order) and you're tasked with getting the set of all rows in PDCampaignBatch_temp that aren't in PDCampaignBatch. The most effective way to do that is to make use of the EXCEPT operator, which will deal with NULL in the expected way as well:
SELECT * FROM [Telemarketing].[dbo].[PDCampaignBatch_temp]
EXCEPT
SELECT * FROM [Telemarketing].[dbo].[PDCampaignBatch]
In production code that is not a one-off, don't use SELECT *, write out the column names instead.
Most likely your issue is with the datetime. You may be only displaying a certain degree of percision like the year/month/date. The data may be stored as year/month/date/hour/minute/second/milisecond. If so you have to match down the the most granluar measurement of the data. If one field is a date and the other is a date time they also will likely never match up. Thus you always get no responses.
I am retreiving values from a Table which in turn i am comparing with values from another table using the SQL keywords 'EXCEPT'
My query looks something like follows
SELECT DISTINCT TDC_TREE_FAMILY_CLASSIFICATION AS DPC_Level1,
TDC_TREE_CLASSIFICATION AS DPC_Level2,
TDC_TREE_SUB_CLASSIFICATION AS DPC_Level3
FROM TD_DATA_PACK_CONTENTS
EXCEPT
SELECT DPC_Level1,DPC_Level2,DPC_Level3 FROM DATA_PACK_CATEGORIES
ORDER BY DPC_Level1
Now this query works fine . What i want to do is save the results in a single string variable.
So I declare 3 temps variables to save the values of DPC_Level1,Lvl2,Lvl3 and then i can join them into a single string variable.
So i modify my Query like this.
SELECT DISTINCT #m_DPC_Level11=TDC_TREE_FAMILY_CLASSIFICATION AS DPC_Level1
,#m_DPC_Level2=TDC_TREE_CLASSIFICATION AS DPC_Level2,
,#m_DPC_Level13=TDC_TREE_SUB_CLASSIFICATION AS DPC_Level3
FROM TD_DATA_PACK_CONTENTS
EXCEPT
SELECT DPC_Level1,DPC_Level2,DPC_Level3 FROM DATA_PACK_CATEGORIES
ORDER BY DPC_Level1
But this throws the error
'A SELECT statement that assigns a value to a variable must not be
combined with data-retrieval operations'
. How i resolve this issue. I am using SQL Server 2008
I would go for a subquery
select #m_DPC_LEvel11 = DPC_Level1,
#m_DPC_Level2 = DPC_Level2,
#m_DPC_Level13 = DPC_Level3,
FROM
(SELECT DISTINCT TDC_TREE_FAMILY_CLASSIFICATION AS DPC_Level1,
TDC_TREE_CLASSIFICATION AS DPC_Level2,
TDC_TREE_SUB_CLASSIFICATION AS DPC_Level3
FROM TD_DATA_PACK_CONTENTS
EXCEPT
SELECT DPC_Level1,DPC_Level2,DPC_Level3 FROM DATA_PACK_CATEGORIES
ORDER BY DPC_Level1) s
This might be a bad idea but just wondering?
;with Products
AS
(
/* can you have an if statement in here? */
select * from products
/* or */
select * from products
where condition
)
what i'm thinking is what if sometimes you have a search string or not. How do you make that a consideration in cte?
Or maybe it would be a better idea to have 2 cte in one procedure?
If you're passing in a search string as a parameter, you can check that it is null or not all in one statement. For example:
select *
from MyTable
where MyColumn = #SearchString
or #SearchString is null;
This will return records that match when the parameter is not null, and return all records when it is null.
As another option, you can always put case statements in your where clause.
Beyond that, if you truly need different queries, you can certainly branch with if BUT your query must be the very next statement after you declare the CTE. Thus you'd have to have a copy or your CTE and query in each branch of the if statement.
If you're thinking of passing an entire where clause and running it all as dynamic SQL (edit: meaning a non-parameterized concatenated string, not ORM-type sp_executesql), I would try refactoring to use any of the above methods first, as there are inherent problems with dynamic SQL. Dynamic SQL often looks clever and elegant at the outset, but should more often be seen as a last resort only when other options somehow turn out to be worse.
table variable might also help you. Check if it helps..
DECLARE #tbl TABLE(id int,name varchar(500), .... )
if <#booleanexpression = 1>
INSERT INTO #tbl select * from products
else
INSERT INTO #tbl select * from products where condition..
with cte as
( select * from #tbl )
select * from cte
I have a valid SQL select which returns an empty result, up and until a specific transaction has taken place in the environment.
Is there something available in SQL itself, that will allow me to return a 0 as opposed to an empty dataset? Similar to isNULL('', 0) functionality. Obviously I tried that and it didn't work.
PS. Sadly I don't have access to the database, or the environment, I have an agent installed that is executing these queries so I'm limited to solving this problem with just SQL.
FYI: Take any select and run it where the "condition" is not fulfilled (where LockCookie='777777777' for example.) If that condition is never met, the result is empty. But at some point the query will succeed based on a set of operations/tasks that happen. But I would like to return 0, up until that event has occurred.
You can store your result in a temp table and check ##rowcount.
select ID
into #T
from YourTable
where SomeColumn = #SomeValue
if ##rowcount = 0
select 0 as ID
else
select ID
from #T
drop table #T
If you want this as one query with no temp table you can wrap your query in an outer apply against a dummy table with only one row.
select isnull(T.ID, D.ID) as ID
from (values(0)) as D(ID)
outer apply
(
select ID
from YourTable
where SomeColumn = #SomeValue
) as T
alternet way is from code, you can check count of DataSet.
DsData.Tables[0].Rows.count > 0
make sure that your query matches your conditions