quote:

---

Originally posted by MIK_2008

Also, I don't know why are you using the Group by clause and Compute Sum .... as there is no aggregate function used in the Select so seems meaningless for me ... Check the following query if this works (i have removed the unnecessary checks in the where clause which are already imposed in the Joining by the ON operator)

select
s.meta_ID, a.address1a, a.address1b, a.city1, a.state1, a.zip1,a.badaddress1,a.mailflag,p.lastname,p.firstname,
s.IDtype,s.stattype,s.gamingdate,s.Twin
from Cds_Account a (nolock)
INNER join Cds_Player p (nolock) on a.account_ID=p.account_ID
INNER join Cds_Statday s (nolock) on p.account_ID=s.meta_ID
where s.IDtype='p'
and a.address1a is not null and a.address1a<>''
and (a.state1='AZ' or a.state1='Arizona')
and s.stattype like 'SL%'
and a.mailflag= 'Y'
and a.badaddress1 = 'N'
and s.gamingdate>= '12/25/10'
and s.twin>=10

Cheers!
MIK

---

select s.meta_ID, a.address1a, a.address1b, a.city1, a.state1, a.zip1,a.badaddress1,a.mailflag,p.lastname,p.firstname,
s.IDtype,s.stattype,s.gamingdate,s.Twin 
INTO #TEMP
from Cds_Account a (nolock)
...
SELECT * FROM #TEMP

quote:

---

Originally posted by Kristen

Query Analyzer is obsolete, so there may not be many people here who use it, or have an opinion on the matter. I use it, it crashes several times a week, I ignore it and restart it.

Maybe your query is failing at the server end, and QA is sitting patiently waiting for a reply. Anything in the server's LOG folder - particularly an exception "crash dump" report? I presume if you are using QA that you are using SQL 2000 and that used to cough at a number of complex queries (but raised an exception report when it did) - if you are not on SP4 then it would be worth considering applying that. (But maybe you are connecting QA to a later version of SQL - that's what I do)

Can you fudge it with:

select s.meta_ID, a.address1a, a.address1b, a.city1, a.state1, a.zip1,a.badaddress1,a.mailflag,p.lastname,p.firstname,
s.IDtype,s.stattype,s.gamingdate,s.Twin 
INTO #TEMP
from Cds_Account a (nolock)
...
SELECT * FROM #TEMP

??

And you know that the NOLOCK hint is the work of the devil? I don't suppose that is the cause because the side effects of NOLOCK are virtually unrepeatable, so it would be unlikely to cause the same effect twice, but as a separate issue if this is a query intended to be used by end users, not solely DBAs who know the consequences of NOLOCK, then there is a high risk that those users will be making business decisions based on inaccurate data - NOLOCK retrieves dirty data that is inappropriate for a report such as this very infrequently, but it does happen.

---

quote:

---

Originally posted by MIK_2008

I am not sure if someone can exactly identify the reason for your issue as we can just guess upon the given information .. there might be some thing which we are missing ... If you can provide some sample data of the tables in joins along with your desired output, we will be able to check your query against that data and may be some of us will let you know if its the problem in Query or anything else!


Cheers!
MIK

---