September 8, 2006 at 12:30 pm
2589 1462
2592 1466
2680 1546
2790 1550
2896 1462
2966 1466
select
b.in_TaskID, a.in_StepIDfrom step as a inner join step as b
on a.in_StepID = b.in_StepID
group
by b.in_TaskID, a.in_StepID
order
by b.in_TaskID
Thank you very much for any help. I'm sure I'll need more once we get this part working.
em
P.S. I had to edit this when my manager complained that I had real information And Lucky suggested the table structure. Hopefully, this is what is meant:
CREATE TABLE [TD_TASK_STEP](
[in_StepID] [int] IDENTITY(1,1) NOT NULL,
[dc_UnitsMultiplier] [decimal](14, 8) NULL,
[dc_UnitsMultiplierCorp] [decimal](14, 8) NULL,
[tx_StepDesc] [varchar](900) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL,
[tx_Comments] [varchar](1024) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
[in_StepOrder] [int] NOT NULL,
[in_CorpStepID] [int] NULL,
[tx_UserName] [varchar](8) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
[dt_LastChanged] [datetime] NULL,
[in_ContentID] [int] NOT NULL,
[in_TaskID] [int] NOT NULL,
CONSTRAINT [PK__TD_TASK_STEP] PRIMARY KEY CLUSTERED
(
[in_StepID] ASC
) ON [PRIMARY]
) ON [PRIMARY]
September 8, 2006 at 12:39 pm
Hello,
Can you post the table structures which you are using in your query? It might give an insight for anybody to help you out.
Thanks
Lucky
September 8, 2006 at 3:04 pm
Try this query in your production environment:
select
*
from
dbo.TD_TASK_STEP a
where
exists ( select
1
from
dbo.TD_TASK_STEP b
where
b.in_StepID <> a.in_StepID
and b.in_TaskID = a.in_TaskID)
hth
September 8, 2006 at 3:18 pm
declare @TD_TASK_STEP table (
in_StepID int,
in_TaskID int
)
insert into @TD_TASK_STEP
select 2589, 1462 union all
select 2592, 1466 union all
select 2680, 1546 union all
select 2790, 1550 union all
select 2896, 1462 union all
select 2966, 1466
SELECT in_StepID, a.in_TaskID
FROM @TD_TASK_STEP a
INNER JOIN (
SELECT in_TaskID
FROM @TD_TASK_STEP
GROUP BY in_TaskID
HAVING COUNT(*) > 1
) b
ON a.in_TaskID = b.in_TaskID
September 8, 2006 at 4:48 pm
Emma,
Both Lynn and John solutions will work for finding the duplicates... the question is, what do you want to do with them once you've found them?
--Jeff Moden
Change is inevitable... Change for the better is not.
September 11, 2006 at 7:03 am
September 11, 2006 at 8:13 am
Yes, it does make sense... What I'd recommend is writing a script that would populate a working table (permanent table that will last until this problem is resolved and then deleted) that captures your duplicate conditions and has a column where you could mark the records for deletion. An automated process (built to do as you have described) would make the first update to the deletion column. Then, a review (manual and by script) could be made to assure that there are no exceptions. Fine tuning would be accomplished by manually changing the deletion flag for individual records.
When complete, a simple delte using the working table as the driver could be accomplished.
--Jeff Moden
Change is inevitable... Change for the better is not.
September 20, 2006 at 6:57 am
September 20, 2006 at 7:01 am
Why the heck does he have access to the PRODUCTION TABLES ?
September 20, 2006 at 7:59 am
I never ask that question because the answer is usually something that raises my hackles
It's usually ok for Developers to have read access but I like what we do better... we make a "clone" (not sure that's the right word) of the DB using our SAN software and, at midnight, we replace the reporting DB lock, stock, and barrel except for the DB where the Developers can keep their code. It's sometimes a bit of a problem because their data will get overwritten unless they store it in the dev DB (like they're supposed to) but, for the most part, it's worked out really well.
--Jeff Moden
Change is inevitable... Change for the better is not.
September 20, 2006 at 1:22 pm
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply