Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
MSSQL Trigger z parametrem
44 views
Skip to first unread message
Pancio
Aug 24, 2020, 4:52:26 AM8/24/20
to
Witam wszystkich,
Mam nadzieję, że grupa jeszcze nie umarła, choć od dłuższego czasu niewiele się tutaj dzieje. No ale do rzeczy.
Mam sobie bazę w MS SQL Server 2014 (wersja Express). Do bazy użytkownicy łączą się z aplikacji w Delphi XE7 z poziomu FireDAC jako jeden użytkownik "sa" (tak, wiem, że nie tak powinno to wyglądać, ale jednak jest jak jest).
Oczywiście jest tabela z danymi zalogowanych użytkowników i nadanych im numerów ID.
No i o ile cała aplikacja bazodanowa działa nawet dość sprawnie i generalnie spełnia swoje zadania, to nadszedł czas rozbudowy aplikacji o dziennik zdarzeń. Chodzi po prostu o to, żeby w osobnej tabeli np. "Dziennik" zapisywane były zmiany typu kto, co i w jakiej tabeli zmienił.
Sprawę w tym momencie załatwiłby wyzwalacz, ale nie mam pomysłu w jaki sposób do triggera przekazać jeden parametr będący numerem ID użytkownika, który danej zmiany dokonał.
Czy w ogóle można to jakoś wykonać? Alternatywą jest obsługa takiego dziennika nie z poziomu bazy danych, a z samej aplikacji. Tyle, że roboty z tym trochę więcej.
Bardzo proszę o pomoc osoby, które już zetknęły się z podobnym problemem.
Dzięki,
Pancio
Mam nadzieję, że grupa jeszcze nie umarła, choć od dłuższego czasu niewiele się tutaj dzieje. No ale do rzeczy.
Mam sobie bazę w MS SQL Server 2014 (wersja Express). Do bazy użytkownicy łączą się z aplikacji w Delphi XE7 z poziomu FireDAC jako jeden użytkownik "sa" (tak, wiem, że nie tak powinno to wyglądać, ale jednak jest jak jest).
Oczywiście jest tabela z danymi zalogowanych użytkowników i nadanych im numerów ID.
No i o ile cała aplikacja bazodanowa działa nawet dość sprawnie i generalnie spełnia swoje zadania, to nadszedł czas rozbudowy aplikacji o dziennik zdarzeń. Chodzi po prostu o to, żeby w osobnej tabeli np. "Dziennik" zapisywane były zmiany typu kto, co i w jakiej tabeli zmienił.
Sprawę w tym momencie załatwiłby wyzwalacz, ale nie mam pomysłu w jaki sposób do triggera przekazać jeden parametr będący numerem ID użytkownika, który danej zmiany dokonał.
Czy w ogóle można to jakoś wykonać? Alternatywą jest obsługa takiego dziennika nie z poziomu bazy danych, a z samej aplikacji. Tyle, że roboty z tym trochę więcej.
Bardzo proszę o pomoc osoby, które już zetknęły się z podobnym problemem.
Dzięki,
Pancio
jast
Aug 25, 2020, 2:18:10 AM8/25/20
to
W dniu 2020-08-24 o 10:52, Pancio pisze:
Rzuć okiem na to
https://www.red-gate.com/simple-talk/sql/database-administration/pop-rivetts-sql-server-faq-no.5-pop-on-the-audit-trail/
Drobny problem może być zapisanie ID użytkownika. Najprościej zrobić to
przez tabelę logowań, w której będziesz zapisywał logowania użytkowników
do aplikacji, zapisując w niej identyfikator sesji procesu (SPID pobrany
przez select @@SPID). W triggerze pobierzesz ten SPID i z tabeli logowań
odczytasz dane użytkownika. Oczywiście po wylogowaniu użytkownika z
aplikacji stosowny rekord z tabeli logowań należy usunąć :-)
https://www.red-gate.com/simple-talk/sql/database-administration/pop-rivetts-sql-server-faq-no.5-pop-on-the-audit-trail/
Drobny problem może być zapisanie ID użytkownika. Najprościej zrobić to
przez tabelę logowań, w której będziesz zapisywał logowania użytkowników
do aplikacji, zapisując w niej identyfikator sesji procesu (SPID pobrany
przez select @@SPID). W triggerze pobierzesz ten SPID i z tabeli logowań
odczytasz dane użytkownika. Oczywiście po wylogowaniu użytkownika z
aplikacji stosowny rekord z tabeli logowań należy usunąć :-)
Miroo
Aug 25, 2020, 4:58:03 AM8/25/20
to
W dniu 2020.08.24 o 10:52, Pancio pisze:
Ja w większości tabel mam datę modyfikacji i id użytkownika
modyfikującego, co załatwiłoby temat.
Ale to by było u Ciebie za dużo zmian.
Inne opcje:
- przekazywać id użytkownia w Application name (w connection string)
- skorzystać z CONTEXT_INFO()
- przy budowaniu połączenia tworzyć tabelę tymczasową z potrzebnymi
danymi (może wpłynąć na wydajność, jeśli często tworzysz połączenia)
- tabela sesji
- i pewnie parę innych pomysłów by się znalazło...
Dodatkowo można skorzystać np z host_name(), aby odczytać nazwę
komputera klienta (w przypadku aplikacji desktopowej).
Pozdrawiam
modyfikującego, co załatwiłoby temat.
Ale to by było u Ciebie za dużo zmian.
Inne opcje:
- przekazywać id użytkownia w Application name (w connection string)
- skorzystać z CONTEXT_INFO()
- przy budowaniu połączenia tworzyć tabelę tymczasową z potrzebnymi
danymi (może wpłynąć na wydajność, jeśli często tworzysz połączenia)
- tabela sesji
- i pewnie parę innych pomysłów by się znalazło...
Dodatkowo można skorzystać np z host_name(), aby odczytać nazwę
komputera klienta (w przypadku aplikacji desktopowej).
Pozdrawiam
Pancio
Aug 25, 2020, 7:13:44 AM8/25/20
to
Co w sytuacji, gdy użytkownik uruchomi dwa rady aplikację. Wtedy otrzyma dwie różne @@SPID.
A co jeśli ktoś uruchomi dwu-, lub trzykrotnie aplikację, albo wyjdzie z niej zabijając jej proces, a nie przez opcję "Wyjdź z programu"? Wtedy dla danego użytkownika będzie wygenerowane więcej niż jeden identyfikator @@SPID.
Jeśli to jakoś sensownie dałoby się załatwić, to rozwiązanie jest w zasadzie wszystkim czego mi potrzeba.
--
Pancio
Miroo
Aug 25, 2020, 7:43:43 AM8/25/20
to
W dniu 2020.08.25 o 13:13, Pancio pisze:
Dwa różne SPID dla jednego użytkownika w niczym nie będą przeszkadzać.
Po prostu będą przy nich te same dane. Raczej nie ma znaczenia, z której
instancji programu użytkownik coś zrobił, tylko że on to zrobił.
Przy wpisywaniu SPID do tabeli trzeba usunąć/zaktualizować wpis z tym
samym SPID. Usuwanie przy wylogowywaniu nie jest wtedy konieczne, chyba
że chcemy to wykorzystać do monitorowania aktualnie zalogowanych
użytkowników.
Pozdrawiam
Po prostu będą przy nich te same dane. Raczej nie ma znaczenia, z której
instancji programu użytkownik coś zrobił, tylko że on to zrobił.
Przy wpisywaniu SPID do tabeli trzeba usunąć/zaktualizować wpis z tym
samym SPID. Usuwanie przy wylogowywaniu nie jest wtedy konieczne, chyba
że chcemy to wykorzystać do monitorowania aktualnie zalogowanych
użytkowników.
Pozdrawiam
0 new messages