🚀 go-pugleaf

wtorek, 25 sierpnia 2020 o 08:18:10 UTC+2 jast napisał(a):
> W dniu 2020-08-24 o 10:52, Pancio pisze:
> > 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
> 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ąć :-)

Hmm, przyznam szczerze, że to nawet bardzo ciekawe rozwiązanie. Dość proste w realizacji, a dająca dość duże możliwości. Jest tylko jedno "ale", podpowiedz proszę, bo być może zetknąłeś się z tym.
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

W dniu 2020-08-24 o 10:52, Pancio pisze:
> 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

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ąć :-)

W dniu 2020.08.24 o 10:52, Pancio pisze:
> 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
>

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

W dniu 2020.08.25 o 13:13, Pancio pisze:
> wtorek, 25 sierpnia 2020 o 08:18:10 UTC+2 jast napisał(a):
>> W dniu 2020-08-24 o 10:52, Pancio pisze:
>>> 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
>> 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ąć :-)
>
> Hmm, przyznam szczerze, że to nawet bardzo ciekawe rozwiązanie. Dość proste w realizacji, a dająca dość duże możliwości. Jest tylko jedno "ale", podpowiedz proszę, bo być może zetknąłeś się z tym.
> 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.

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