I have an SQL statement
SELECT dbo.sem_computer.COMPUTER_NAME,dbo.sem_computer.COMPUTER_ID,
[IP_ADDR1_TEXT],dbo.sem_computer.COMPUTER_DOMAIN_NAME, [ID],dbo.SEM_AGENT.AGENT_VERSION
FROM sem_computer, [dbo].[V_SEM_COMPUTER], IDENTITY_MAP, SEM_CLIENT,dbo.SEM_AGENT
WHERE [dbo].[V_SEM_COMPUTER].COMPUTER_ID = SEM_COMPUTER.COMPUTER_ID and dbo.IDENTITY_MAP.ID = dbo.SEM_CLIENT.GROUP_ID
and dbo.SEM_COMPUTER.COMPUTER_ID = dbo.SEM_CLIENT.COMPUTER_ID
AND dbo.SEM_COMPUTER.COMPUTER_ID = dbo.SEM_AGENT.COMPUTER_ID
AND NAME = 'My Company\Default Group'
OR NAME = 'My Company\Bronx'
order by [IP_ADDR1_TEXT]
That executed indefinitely and even freezes the SQL server when I tried to copy and paste this code.
If I remove the
OR NAME = 'My Company\Bronx'
then the the SQL statement executes just fine
We are using SQL Server 2008
Thank you
I think this whole problem becomes a lot clearer if you write ANSI-Compliant T-SQL. So rather than have your able join conditions in the WHERE clause, you have something like:
SELECT
dbo.sem_computer.COMPUTER_NAME
, dbo.sem_computer.COMPUTER_ID
, [IP_ADDR1_TEXT]
, dbo.sem_computer.COMPUTER_DOMAIN_NAME
, [ID]
, dbo.SEM_AGENT.AGENT_VERSION
FROM
sem_computer AS COM
INNER JOIN
[dbo].[V_SEM_COMPUTER] AS V
ON
COM.COMPUTER_ID = V.COMPUTER_ID
INNER JOIN
dbo.SEM_CLIENT AS CLI
ON
COM.COMPUTER_ID = CLI.COMPUTER_ID
INNER JOIN
dbo.SEM_AGENT AS AGT
ON
COM.COMPUTER_ID = AGT.COMPUTER_ID
INNER JOIN
IDENTITY_MAP AS IM
ON
CLI.GROUP_ID = IM.ID
...
Then your WHERE clause does what it is designed to do, which is filter your data. This becomes, as suggested earlier
WHERE
NAME IN('My Company\Default Group','My Company\Bronx')
The performance problem you had was, as pointed out, you were getting a cross join of all tables. But I think you would have noticed this if you write your joins in an ANSI compliant way.
I hope that helps.
Ash
OR NAME IN('My Company\Default Group','My Company\Bronx')
Should work.
When you have the AND NAME = 'My Company\Default Group'
OR NAME = 'My Company\Bronx' not in parentheses or using an IN clause, it means that it will get everything where the OR condition is satisfied, ignoring all of the other conditions.
Related
I'm struggling with a problem in SQL - I keep getting this error:
Incorrect syntax: CREATE VIEW must be the only statement in the batch
I'm using newest Microsoft SQL Server Management Studio.
CREATE VIEW [name]
AS
SELECT
Dostawcy.Nazwa_Firmy,
Dostawcy.Szef_Imie,
Dostawcy.Szef_Nazwisko,
Towary.Nazwa,
SUM(Towary_Dostawy.Ilosc) AS Suma
FROM
Dostawcy
INNER JOIN
Dostawy ON Dostawcy.Nazwa_Firmy = Dostawy.Firma_Dostarczajaca
INNER JOIN
Towary_Dostawy ON Dostawy.ID_Dostawy = Towary_Dostawy.ID_Dostawy
INNER JOIN
Towary ON Towary_Dostawy.ID_Towaru = Towary.ID_Towaru
WHERE
Towary_Dostawy.ID_Towaru = 4
GROUP BY
Towary_Dostawy.ID_Towaru, Towary.Nazwa,
Dostawcy.Nazwa_Firmy, Dostawcy.Szef_Imie,
Dostawcy.Szef_Nazwisko
ORDER BY
Suma DESC
SELECT TOP 1 *
FROM name
I checked if the CREATE VIEW was at the beginning of the code, tried something with GO, but maybe wrong.
Add a go to the line above select top 1 * from [name]
Edit: also, the order by should be removed as it has no effect inside of a view.
This query doesnt work when i run this query with tables from sql server as linked back end. But works just fine when tables are from linked ms access back end.
I think it has something to do with the join clause.
SELECT qry_Product_Warehouse.Warehouse_ID, qry_Product_Warehouse.Product_ID,
CDbl(Nz(IIf(IsNull([tbl_Product_Quantity].[Stock_Recount_Date]),
Sum([qry_Product_Transaction].[qty]),
[tbl_Product_Quantity].[Stock_Recount_Quantity]+Sum(IIf([qry_Product_Transaction].[Date]>[tbl_product_quantity].[Stock_Recount_Date],[qry_Product_Transaction].[Qty],0))),0)) AS Current_Qty
FROM (qry_Product_Warehouse
LEFT JOIN qry_Product_Transaction ON (qry_Product_Warehouse.Warehouse_ID = qry_Product_Transaction.Location)
AND (qry_Product_Warehouse.Product_ID = qry_Product_Transaction.Product))
LEFT JOIN tbl_Product_Quantity ON (qry_Product_Warehouse.Product_ID = tbl_Product_Quantity.Product)
AND (qry_Product_Warehouse.Warehouse_ID = tbl_Product_Quantity.Warehouse)
GROUP BY qry_Product_Warehouse.Warehouse_ID, qry_Product_Warehouse.Product_ID, tbl_Product_Quantity.Stock_Recount_Quantity, tbl_Product_Quantity.Stock_Recount_Date;
Hey guys the code below is taking a really long time. I've been looking at it for quite a while. Is there anything that stands out as the obvious cause of delay?
[SQLSRV-3-JB] is a linked server BTW
Select count(cast (Unique_ID as bigint)) as [Count],
T.[Region_Code],
T.[Region_Name],
U.[Region_Code],
Y.[Examination_Year],
case when [Subject] = 'MUSIC THEORY' THEN 'Theory'
else 'Practical'
end
from [SQLSRV-3-JB].[X].[dbo].[Exam_and_Candidate_Details] Y
left join [SQLSRV-3-JB].[X].[dbo].[UK_Exam_Centre_Info] T
on Y.Centre_Code = T.Centre_Code
left join [SQLSRV-3-JB].[X].[dbo].[UK_Exam_Centres] U
on Y.Centre_Code = U.Centre_Code
where Y.[Examination_Year] between 2010 and 2016
group by Y.[Examination_Year],
T.[Region_Code],
T.[Region_Name],
U.[Region_Code],
case when [Subject] = 'MUSIC THEORY' THEN 'Theory'
else 'Practical'
end
Yes, there is one very obvious problem - the remote server. When you use a linked server like this, SQL Server has a disturbing habit of pulling all of the data in the remote tables to the local server before performing JOINs or filtration.
The correct way to handle this is to make this query a view on the remote server, and query the view with your WHERE clause on your end. So, your remote code would look like this:
-- Remote Server
USE X
GO
CREATE VIEW dbo.ExamCenterInfo
AS
Select count(cast (Unique_ID as bigint)) as [Count],
T.[Region_Code],
T.[Region_Name],
U.[Region_Code],
Y.[Examination_Year],
case when [Subject] = 'MUSIC THEORY' THEN 'Theory'
else 'Practical'
end
from dbo.[Exam_and_Candidate_Details] Y
left join dbo.[UK_Exam_Centre_Info] T
on Y.Centre_Code = T.Centre_Code
left join dbo.[UK_Exam_Centres] U
on Y.Centre_Code = U.Centre_Code
group by Y.[Examination_Year],
T.[Region_Code],
T.[Region_Name],
U.[Region_Code],
case when [Subject] = 'MUSIC THEORY' THEN 'Theory'
else 'Practical'
end
Then your local code:
-- Local Server
SELECT *
FROM [SQLSRV-3-JB].[X].[dbo].ExamCenterInfo ECI
where ECI.[Examination_Year] between 2010 and 2016
NOTE: There is some possibility that this will pull all of the view output before filtering by year. If this is still a problem, you will have to create a more complex mechanism to execute the view with filtration on the remote server.
I tried searching around but couldn't find anything that would help me out.
SELECT COL1,* FROM TAB1 A
JOIN TAB2 b ON A.ID=B. ID
INNER JOIN TAB3 C ON C.AsOf=A.AsOf
WHERE
B.AsOf BETWEEN
(
CASE WHEN C.DayOfWeek = 7 AND C.IsCalendarMonthEnd = 'Y'
THEN DATEADD(dd,-1,C.PreviousCalendarDay) AND DATEADD(dd,+1,C.AsOf)
END
)
i am getting error like 'Incorrect syntax near the keyword 'AND''
i need find dates between dates basid on case statment
if possible?
Unfortunately, error messages from Oracle in particular (you don't say which database server you're using) can be maddeningly unclear about where the error lies.
The problem is here:
JOIN TAB2 b ON A.ID=B. ID AND
INNER JOIN TAB3 C ON C.AsOf=A.AsOf
You don't want the AND there. It's a syntax error.
There's an issue with your WHERE clause. You can't specify both bounds of the BETWEEN operator in CASE in one go. Possibly what you meant it to be like is this:
…
WHERE C.DayOfWeek = 7
AND C.IsCalendarMonthEnd = 'Y'
AND B.AsOf BETWEEN DATEADD(dd,-1,C.PreviousCalendarDay) AND DATEADD(dd,+1,C.AsOf)
I have run into a rather weird problem. I have created the following query in SQL Server
SELECT * FROM leads.BatchDetails T1
INNER JOIN leads.BatchHeader h ON T1.LeadBatchHeaderId = h.ID
WHERE
T1.LeadBatchHeaderId = 34
AND (T1.TypeRC = 'R' OR h.DefaultTypeRC = 'R')
AND EXISTS (SELECT ID FROM leads.BatchDetails T2 where
T1.FirstName = T2.FirstName AND
T1.LastName = T2.LastName AND
T1.Address1 = T2.Address1 AND
T1.City = T2.City AND
T1.[State] = T2.[State] AND
T1.Zip5 = T2.Zip5 AND
T1.LeadBatchHeaderId = T2.LeadBatchHeaderId
and t2.ID < t1.ID
AND (T2.TypeRC = 'R' OR h.DefaultTypeRC = 'R' )
)
It runs decently fast in 2 seconds. When formatting the code I accidently added an additional SPACE between AND + EXISTS so the query look like this.
SELECT * FROM leads.BatchDetails T1
INNER JOIN leads.BatchHeader h ON T1.LeadBatchHeaderId = h.ID
WHERE
T1.LeadBatchHeaderId = 34
AND (T1.TypeRC = 'R' OR h.DefaultTypeRC = 'R')
AND EXISTS (SELECT ID FROM leads.BatchDetails T2 where
T1.FirstName = T2.FirstName AND
T1.LastName = T2.LastName AND
T1.Address1 = T2.Address1 AND
T1.City = T2.City AND
T1.[State] = T2.[State] AND
T1.Zip5 = T2.Zip5 AND
T1.LeadBatchHeaderId = T2.LeadBatchHeaderId
and t2.ID < t1.ID
AND (T2.TypeRC = 'R' OR h.DefaultTypeRC = 'R' )
)
All of a sudden the query takes 13 seconds to execute.
I am running SQL Server in an isolated sandbox environment and I have even tested it on a different sandbox. I also checked the executed query in profiler, the reads are virtually the same, but CPU time is way up
If this is not weird enough, it's getting weirder. When I change SELECT * FROM to SELECT Field1, ... FROM at the top of the query the execution takes over 3 minutes.
I have been working with SQL Server for 10 years and never seen anything like this.
Edit:
After following the suggestions below it appears that queries are "white-space-sensitive". However I still have no idea why the SELECT * FROM is so much faster than SELECT Field1, ... FROM
I would guess that you're dealing with two different cached query plans:
You you ran the query once, with a certain set of parameters. SQL Server determined an appropriate query plan, and stored that query plan "Auto-parametrized", in other words replacing the values you provided with variables, for the purposes of the query plan.
You then ran the same query again, with different parameters. The query gets auto-parameterized, and matches the existing cached query plan (even though that query plan may not be optimal for the new parameters provided!).
You then run this second query again, with your extra space. This time, the auto-parametrized query does NOT match anything in the cache, and therefore gets its own plan based on THIS set of parameters (remember, the first plan was for a different set of parameters). This query plan happens to end up faster (or slower).
If this is truly the explanation, you should be able to make the effect go away, by running DBCC FREEPROCCACHE: http://msdn.microsoft.com/en-us/library/ms174283.aspx
There's lots of stuff on auto-parameterization out there, I personally liked Gail Shaw's series:
http://sqlinthewild.co.za/index.php/2007/11/27/parameter-sniffing/
http://sqlinthewild.co.za/index.php/2008/02/25/parameter-sniffing-pt-2/
http://sqlinthewild.co.za/index.php/2008/05/22/parameter-sniffing-pt-3/
(for the record, I have no idea whether SQL Server eliminates/normalizes whitespace before storing an auto-parameterized query plan; I would have assumed so, but this entire answer asssumes that it doesn't!)
This might very well be related to caching issues. When you change your query, even by as little as a space, the cached execution plan of your previous query will no longer be used. If my answer is correct, you should see the same (2 seconds) performance when you run the bottom query for the second time...
Just my 2 cents
You could flush the cache with the following two statements:
DBCC FreeProcCache
DBCC DROPCLEANBUFFERS