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:


Owy ciąg znaków 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 WorkstationIdTestDB.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.