SQL Server - Duplicacion en Consultas

Hola a Todos:

Estoy realizando un Stored Procedure el cual me muestra datos de diferentes tablas, cuando ejecuto el StoredProcedure me marca un registro del campo duplicado, mi pregunta es que si se puede mostrar solo una ves ese dato sin que se vea en todos los registros.

Por si no me entienden, este seria un ejemplo

Estoy mostrando lo siguiente (Asi es como me sale la consulta normalmente):

Año AreaGeografica SalarioMinimo

2002 A 61.40
2002 B 58.60
2002 C 55.85
2003 A 63.60
2003 B 61.15
2003 C 58.75

Y asi sucesivamente, lo que yo quiero es que al momento de ejecutar el StoredProcedure, el año me salga solo una ves para el 2002, una para el 2003 y asi.......
Para el arega geografica A que salga el año, para el area geografica B ya no salga, no se si me de a entender. Existe alguna sentencia que me ayude a hacer esto?? o de plano es imposible???? Ojo, esto quiero hacerlo dentro del Enterprise Manager de SQL, el diseño yo lo voy a realizar con ASP.NET, lo quiero hacer dentro de SQL.

Espero me puedan ayudar.

Gracias

Hola,
No, no hay manera de hacerlo en una sentencia SQL, deberías hacerlo en la presentación.
Saludos,
Liliana.

LEI LOS COMENTARIOS DE NUESTRO COLEGA DICIENDO QUE NO SE PUEDE...QUE PASA EN SQL TODO SE PUEDE HACER...

HICE ESTE CODIGO YA LO PROBE SI FUNCIONA, UNICAMENTE QUE LO EJECUTE DESDE EL ANALIZADOR DE CONSULTAS, TU LOPODRIAS PONER EN UN PROCEDIMIENTO ALMACENADO TE DEVOLVERIA UNA TABLA QUE FACILMENTE PODRIAS MOSTRAR.

MANDO EL SCRIPT Y EL CODIGO DE LA TABLA QUE YO HICE CON LOS DATOS QUE PUSISTES.

create table #consulta(
anio int,
area char(1),
salariom numeric(12,2) )

declare @anio int ,@area char(1),@salariom numeric(12,2),@cuantos int
set @cuantos=0

DECLARE Csalario CURSOR FOR
SELECT anio,AREA,SALARIOM FROM SALARIO
order by anio,area

OPEN Csalario

FETCH NEXT FROM Csalario into @anio,@area,@salariom
WHILE @@FETCH_STATUS = 0
BEGIN
begin
select @cuantos=count(*) from #consulta
where anio=@anio
if @cuantos>0
begin
insert into #consulta(anio,area,salariom)
values(null,@area,@salariom)
end
else
begin
insert into #consulta(anio,area,salariom)
values(@anio,@area,@salariom)
end
end
set @cuantos=0
FETCH NEXT FROM Csalario into @anio,@area,@salariom
END

CLOSE Csalario
DEALLOCATE Csalario
select * from #consulta
drop table #consulta

---/////////
if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[salario]') and OBJECTPROPERTY(id, N'IsUserTable') = 1)
drop table [dbo].[salario]
GO

CREATE TABLE [dbo].[salario] (
[anio] [int] NULL ,
[area] [char] (1) COLLATE SQL_Latin1_General_CP850_CI_AI NULL ,
[salariom] [decimal](18, 2) NULL
) ON [PRIMARY]
GO

[email protected]

TE MANDE ALGO MAS A TU CORREO... SALUDOS

Hola Francisco,
Gracias por el envío.
Si me permitís un comentario, más allá del resultado obtenido con la consulta, la práctica de cursores no es adecuado cuando trabajás con un volumen importante de información. Cualquier cosa que hagas con cursores puede hacerse sin ellos, y el tiempo de proceso y aprovechamiento de recursos seguramente será mejor, he podido comprobarlo.

Hice esta consulta, que devuelve los mismos resultados que la tuya y consume nueve veces menos recursos, aunque para quienes están acostumbrados a trabajar con cursores les será más complicado leerla.
La idea es seleccionar el primer área de cada año, que llevaría todos los datos en el renglón, uniéndolo al resto de la información, clasificando por una columna año creada para el listado:

SELECT anionuevo, area, salariom
FROM
(
-- selecciona el primer area para cada año
SELECT sal.anio, anionuevo = sal.anio, sal.area, salariom
FROM
(
SELECT anio, area = min(area)
FROM #salario
GROUP BY anio) minimo
INNER JOIN #salario sal
ON sal.anio = minimo.anio and sal.area = minimo.area

UNION

-- selecciona todas las areas menos la menor (ver condición del JOIN)
SELECT sal.anio, anionuevo = 0, sal.area, salariom
FROM
(
SELECT anio, area = min(area)
FROM #salario
GROUP BY anio) minimo
LEFT JOIN #salario sal
ON sal.anio = minimo.anio and sal.area > minimo.area) derivada
ORDER BY anio, anionuevo DESC, area

Te reitero, no me parece que esta sea una buena práctica cuando se puede resolver desde la presentación de los datos. Cada uno en lo suyo, el servidor debe dedicarse a otras cuestiones más relevantes.
Saludos,
Liliana.