Workstation ID i HOST_NAME

Kiedyś zostałem zmuszony do szybkiego, nawet bardzo szybkiego, zrealizowania zagadnienia: “archiwizacja poczynań użytkownika w systemie“. Prościej rzecz ujmując, rejestracji 3 podstawowych operacji na każdej tabeli, a dokładniej jej wierszach, mianowicie: INSERT, UPDATE, DELETE. Poniżej zaprezentuję jak uporałem się z tym zagadnieniem.

Zacznę więc od początku. Workstation ID – cóż to jest takiego? Jest to jeden z wielu parametrów, który można umieścić w ConnectionString. Domyślnie przyjmuje on wartość nazwy komputera, jednakże możemy go zastąpić dowolnym ciągiem znaków (maksymalna długość to 125). Przykładowy ConnectionString wyglądałby następująco:

connectionString="Data Source=.\sqlexpress;Initial Catalog=WorkstationIdTestDB; Integrated Security=True;Workstation ID=\"flip i flap\""

Workstation ID po stronie serwera możemy wyciągnąć za pomocą wbudowanej funkcji HOST_NAME zwykłym zapytaniem:

SELECT HOST_NAME()

Dzięki tym dwom aspektom rejestrowałem, kto dokonywał zmiany w systemie. Z racji tego iż była to aplikacja webowa, a do komunikacji z bazą danych posługiwałem się narzędziem LINQ to SQL Classes, zmodyfikowałem
lekko konstruktor do tworzenia kontekstu mojej bazy, który po modyfikacji mógłby przedstawiać się jak przykład poniżej. Nadmienię również, że konstruktor zadeklarowany był w pliku “designer.cs“, należący do dbml’a.

public WorkStationIdTestDataContext() : 
	base(global::WorkstationIdTest.Properties.Settings.Default.WorkstationIdTestDBConnectionString, mappingSource)
{
	var userMS = System.Web.Security.Membership.GetUser();
	if (userMS != null)
	{
		Connection.ConnectionString += string.Format(";Workstation ID=\"{0}\"",
			userMS.ProviderUserKey.ToString());
	}
	OnCreated();
}

Od strony kodu to wszystko. Należało tylko pamiętać, iż jakakolwiek zapisana zmiana pliku dbml generowała konstruktor na nowo, co determinowało ponowne wprowadzanie zmian.

Od strony bazy było więcej pracy. Mianowicie, Microsoft SQL Server Database Publishing Wizard zeskryptował wszystkie tabele. Za pomocą magicznego [CTRL] + [H] wyszukałem “[dbo].[“, a zamieniłem na “[arch].[“. Usunąłem wszystkie klucze zewnętrzne i indeksy, ponieważ uznałem iż nie będą potrzebne w tabelach archiwalnych. Do każdej tabeli dołożyłem 3 nowe kolumny (ChangedBy, ChangedDate, ChangedType) oraz indeksy na dwóch pierwszych z nich. Następnie stworzyłem sobie generator triggerów, czyli funkcję której podawałem nazwę tabeli, a ta sklejała mi 3 triggery odpowiedzialne za dodawanie wierszy do tabel archiwalnych. Poniżej znajduje się przykładowe zapytanie, które dostarcza nazwy wszystkich tabel w bazie oraz jeden przykładowy trigger.

SELECT [name] FROM sys.tables
CREATE TRIGGER [dbo].[tr2Note] 
   ON   [dbo].[Note]
   AFTER UPDATE
   AS
BEGIN
   INSERT INTO [arch].[Note]
   SELECT inserted.*, HOST_NAME(), GETDATE(), 2
   FROM inserted
END

Osobiście myślę, że sposób nie jest najlepszy, jednakże bardzo szybki do implementacji. Ukazuje on wykorzystanie Worksation ID w aplikacji oraz HOST_NAME w bazie danych.

Promuj

Facebook
Twitter
LinkedIn
Google+
http://kurzyniec.pl/artykuly/workstationid-hostname/

One thought on “Workstation ID i HOST_NAME

Leave a Reply

Your email address will not be published. Required fields are marked *