Trigger og linked server

Kan du ikke styre dette med rettigheder på brugerniveau?

I SQL Server 2000 mener jeg ikke der er ikke muligheder for at lave triggers som du spørger efter, da triggers her kun kan ligge på tabelniveau. Jeg ved SQL Server 2005 har fået udvidet brug af triggers, som også kan bruges bl.a. på ddl niveau (ændring af metadata).

Men i udganspunktet vil jeg mene at det er bedre at sørge for at brugerne ikke har mulighed for at inserte records på sqlserver2.

Der er flere muligheder... Jeg vil først lige høre, du siger en tabel på sqlserver2, hvis du bruger linked servers er det jo ikke en fysisk tabel du tilgår - hvad mener du her?
Du skriver også af sikkerhedsmæssige årsager - betyder det at der ikke må læses eller skrives?

Du kan ikke oprette en trigger på en server der kan overvåge en anden server på den måde, men du kan skrive en after update trigger på sqlserver2 som indsætter en slage "history-of-changes" til en lokal tabel og lade denne tabel blive overvåget af sqlserver1.

Situationen er som følger:
Sqlserver 2 ligger i en dmz-zone og må ikke have forbindelse til sqlserver 1, da det giver mulighed for en eventuel hacker at komme i kontakt med driftdatabasen (sqlserver1). I sqlserver2 indsættes der records i en tabel. Disse records skal flyttes ned i en tilsvarende tabel på sqlserver1. Det er kun muligt at lave en linked server fra sqlserver1 til sqlserver2, sådan at man fra sqlserver1 kan se tabellen i sqlserver2. Da jeg gerne vil have flyttet records når de lander i sqlserver2, ville jeg bare gerne vide om man kunne lave en trigger på sqlserver1, der reagerede på at der blev indsat records på sqlserver2.

Okay... normalt ville man jo nok have opnået den funktionalitet med replikering, men i og med du skriver du kun kan bruge en linked server vil jeg råde dig til følgende:

Test:

create table MyTable
(
id int identity(1,1),
fname varchar(25),
hostname varchar(25) default host_name()
)


create table MyHistory
(
id int,
fname varchar(25),
added datetime default getdate()
)

create trigger tr_mytrigger on MyTable instead of insert as
begin

declare @hostname varchar(25)
declare @fname varchar(25)


        select @hostname = hostname, @fname = fname from inserted

        insert into MyTable(fname, hostname) values(@fname, @hostname)

        if @hostname = 'CLI001' //skift ud med dit servernavn
            insert into MyHistory(id, fname)
                select @@identity, @fname from inserted

end

prøv at indsætte : insert into mytable (fname) values('qwe')
select * from MyHistory
select * from MyTable

Nu skal du så evt. vha. et job der kører på sqlserver1 overvåge inserts ind i MyHistory, derved kan du se at de inserts er kommet ude på sqlserver2 og ikke via sqlserver1!

Det er en lidt bøvlet måde at gøre det på.... du kunne måske evt. indsætte vha. den trigger en insert direkte ind på sqlserver1 - til det kan du bruge.. snippet fro BOL:
USE pubs
GO
SELECT a.*
FROM OPENROWSET('SQLOLEDB','seattle1';'sa';'MyPass',
  'SELECT * FROM pubs.dbo.authors ORDER BY au_lname, au_fname') AS a
GO


Som du kan se kan du faktisk gemme connectionen i triggeren og derved gemme det for en evt. hacker.
Du kan også som sidste løsning lave en linked server (og ja det vil du måske ikke), men så kun give den rettighed til at indsætte ind i historytabel på sqlserver1 :-)

Der er mange muligheder, håber du kan bruge nogle af dem.

Jeg vil kigge på det du har skrevet, og hvis du smider et svar, kan du få nogle point. Jeg vil stadig prøve din løsning med en trigger, selv om jeg på nuværende tidspunkt har løst problemet med en windows service, der alligevel kører på sqlserver1. Da denne service fungerer med en timer, har jeg indsat kode i den til at tjekke om der er nye records der skal hentes.

Hvis du ikke har behov for real time opdatering, kan du jo også lave en DTS pakke på sqlserver1 (eller sqlserver2), som checker for nye records. Denne kan du schedulere til at køre med bestemte interval, noget du også kan gøre fra SQL Server (SQL Server Agent/Jobs).

Det skal være real time opdatering, men da systemet ikke kan stå stille lige nu, har jeg været nødt til at finde en anden løsning indtil en real time løsning er implementeret.

Hvis I bruger SQL Server 2005, og du ikke umiddelbart finder en løstning med triggers, så er SQL Server Broker en oplagt mulighed:
http://msdn2.microsoft.com/en-us/library/ms166043.aspx

Jeg håber du får det til at virke, ellers vil jeg gerne hjælpe dig videre...

lorentsnv-> Ja du har helt ret, der er nogle fordele lige i det scenarie med ServiceBrokeren, men så igen... en ServiceBroker vil måske rent vedligeholdelsesmæssigt være lidt af en udfordring til noget så simpelt.

Den korrekte måde at gøre det på(imho) er vha. replikering og så fjerne alle skriverettigheder på subscriberen (i det her tilfælde sqlserver2), men det kan ikke rigtigt lade sig gøre i det scenarie her som jeg forstår det.

Hygge

Ville meget gerne benytte SQL Server 2005, men da løsningen ligger hos en stor hosting virksomhed, har jeg ikke mulighed for at opgradere til denne version, desværre :-(