QA returning inconsistent records

Here's perhaps the most bizarre thing I've seen from SQL Server in a long time.  I have two tables, TiMaster (1.2million recs) and Staff (300 recs) and an application that gets inconsistent results.  So I ran the sql statements directly in Query Analyzer and found differing results, from time to time.

Is there something wrong with my statement syntax? The only thing I can think of is the "T.STAFF IN (..." part of the Where clause might not handle strings the way I expect.  I've used it consistently with a set of integers, but maybe 'AS' would be treated as found in a list containing 'ASX'?

Here are the statements:

Select
      S.NAME, T.STAFF, T.MATTER_ID, SUM(T.HOURS) AS ATTYHOURS, T.TEAM,
      SUM(0) AS ASSTHOURS, SUM(T.ORIG_AMT) AS ATTYAMOUNT,
      SUM(0) AS ASSTAMOUNT, T.MATTER_ID AS MATTERID, S.NAME
From
      TIMASTER T, STAFF S
Where
      (T.IS_ATTY<>0) AND
      (T.ACCT_NO IN (16914462)) AND
      (T.STAFF IN ('ASB', 'BLP', 'VT')) AND
      ((T.EFF_DATE >= '2003-07-01') AND (T.EFF_DATE < '2004-07-01')) AND
      (T.STAFF = S.STAFF_ID)
Group By
      S.NAME, T.STAFF, T.MATTER_ID, T.TEAM , S.NAME
ORDER BY
      S.NAME

This one returns consistently a set of records for user 'VT' which total 1,151 hours.  But when I add more users, with everything else identical, the number of records returned is FEWER (sometimes)!  They usually, but not always, return 296 hours.  Another bizarre twist here is that if I keep the number of STAFF items in the list the same, but shorten the date range, the correct number of hours are returned.

Here's the second one:

Select
      S.NAME, T.STAFF, T.MATTER_ID, SUM(T.HOURS) AS ATTYHOURS, T.TEAM,
      SUM(0) AS ASSTHOURS, SUM(T.ORIG_AMT) AS ATTYAMOUNT,
      SUM(0) AS ASSTAMOUNT, T.MATTER_ID AS MATTERID, S.NAME
From
      TIMASTER T, STAFF S
Where
      (T.IS_ATTY<>0) AND
      (T.ACCT_NO IN (16914462)) AND
      (T.STAFF IN ('ASB', 'BLP', 'CKC', 'DEM', 'DIF', 'DJS', 'EEM',
            'JAP', 'JRO', 'LGT', 'LMM', 'LWP', 'MAL',
            'MWE', 'NTD', 'SRM', 'VT', 'WAJ', 'WDS', 'WS')) AND
      ((T.EFF_DATE >= '2003-07-01') AND (T.EFF_DATE < '2004-07-01')) AND
      (T.STAFF = S.STAFF_ID)
Group By
      S.NAME, T.STAFF, T.MATTER_ID, T.TEAM , S.NAME
ORDER BY
      S.NAME

Any information that might give me clues would be GREATLY appreciated.
bjones8888PresidentAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Ken SelviaRetiredCommented:
You might have some corrupt indexes. Run

DBCC DBREINDEX('TIMASTER')
DBCC DBREINDEX('STAFF')

and see if that makes any difference.
0
bjones8888PresidentAuthor Commented:
That sounded like the perfect solution.  Perfectly explains the differing results, and also explains why I could import all that data into a new database and NOT see different results.  However, after the reindex, I still get the same problem.  

I'm not giving up on the idea of corrupted indices, though.  Unfortunately, I've got about 80 users in the system for another 5-6 hours, but after that I'm planning to do a complete rebuild of the tables and indices.

Would the index rebuild be invalidated / delayed if there are clients using the tables?  The response from QA indicated that the rebuild was complete, but didn't mention anything about errors.
0
Ken SelviaRetiredCommented:
It would have run immediatly.  When you get the users off the system you might also try

DBCC CHECKTABLE ('TIMASTER')
DBCC CHECKTABLE ('STAFF')

What are the datatypes of T.HOURS and T.ORIG_AMT?
0
bjones8888PresidentAuthor Commented:
Sorry for the long delay here.  I tried all of the above, including DBCC CHECKDB.  None of that had any effect.  The indices and tables reported no errors.

However, here's what worked.  In the Where clause, when I changed "(T.STAFF IN ('ASB', ..." to "(S.STAFF_ID IN ('ASB', ...", it worked perfectly.  I'm clueless as to why, though.  I'm still willing to award the points to whomever can tell me why.  I thought specifying the staff criteria on the TiMaster table would be more appropriate (that's the detail of all time records).  The STAFF table is, obviously, one record per staff member.  You'll see one of the criteria in the Where clause is (T.STAFF = S.STAFF_ID).

Two questions:  1. Why would my change make such a difference?  and, 2. Is there a difference in how that type of statement was implemented in different versions of SQL Server?  (Remember, my copy of their data worked every time.  I'm on SQL 2000 and my client is probably on SQL Server 7.0.)
0
Computer101Commented:
PAQed, with points refunded (250)

Computer101
E-E Admin
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft SQL Server

From novice to tech pro — start learning today.