🚀 go-pugleaf

W dniu 07-07-2017 o 17:10, Pancio pisze:
> Witam,
> Zaczynam pisac aplikacje w Delphi XE7, a za silnik bazy danych wybralem MS SQL Express 2014. Aplikacja zaczyna bardzo ladnie mi sie rozbudowywac, ale zapragnalem jednej rzeczy, do ktorej ni jak nie wiem jak sie zabrac.
> Chodzi mi o to, aby dla 3-4 tabel (choc moze i dla wszystkich) tworzony byl swojego rodzaju plik dziennika. Wowczas widzialbym, jaka byla historia zmian danych kolumn. W zasadzie nie potrzebuje nic wiecej poza informacja z data operacji zmiany oraz o poprzedniej wartosci danej kolumny.
> Oczywiscie moge stworzyc dodatkowa tabele, ktora bedzie przychowywac takie informacje, ale czy MS SQL robi to jakos z automatu, czy musze "recznie" oprogramowac takie zdarzenia jak Insert, Update czy Delete.
> Z gory dziekuje za jakies sugestie.
>
> --
> Pancio
>
Nie wiem czego używasz do łączenia z bazą, ale ZEOSY mają coś takiego
jak SQLmonitor i wszystkie zapytania SQL lądują w pliku.
Może to jest dla ciebie, nie koniecznie w samej bazie.

W dniu 2017-07-10 o 12:20, konsul41@wp.pl pisze:
> W dniu 07-07-2017 o 17:10, Pancio pisze:
>> Witam,
>> Zaczynam pisac aplikacje w Delphi XE7, a za silnik bazy danych
>> wybralem MS SQL Express 2014. Aplikacja zaczyna bardzo ladnie mi sie
>> rozbudowywac, ale zapragnalem jednej rzeczy, do ktorej ni jak nie wiem
>> jak sie zabrac.
>> Chodzi mi o to, aby dla 3-4 tabel (choc moze i dla wszystkich)
>> tworzony byl swojego rodzaju plik dziennika. Wowczas widzialbym, jaka
>> byla historia zmian danych kolumn. W zasadzie nie potrzebuje nic
>> wiecej poza informacja z data operacji zmiany oraz o poprzedniej
>> wartosci danej kolumny.
>> Oczywiscie moge stworzyc dodatkowa tabele, ktora bedzie przychowywac
>> takie informacje, ale czy MS SQL robi to jakos z automatu, czy musze
>> "recznie" oprogramowac takie zdarzenia jak Insert, Update czy Delete.
>> Z gory dziekuje za jakies sugestie.
MSSQL posiada mechanizm CDC (google wie o co chodzi), ale nie dla wersji
Express, czyli o tym możesz zapomnieć.
Chcesz automat, to musiałbyś zmienić podejście do programowania DAC o
180 stopni. Co najmniej.
Dlaczego? Ponieważ np. mORMot oferuje podobne możliwości, a także
niektóre ORMy.

Kiedyś robiłem bieda wersję czegoś takiego, co sprowadzało się do
napisania generatora triggerów da określonych tabel (można było sobie
wybrać tabele i ich pola, które mają być monitorowane).
Dane lądowały w innej tabeli.
Potem tylko przeglądarka do tego.
Generalnie sporo pracy, jeśli ma to być zrobione dobrze...

Inny pomysł to obsłużenie tego przez aplikację w 100%; to może być dość
proste do zrobienia, ale trochę też zależy jak ta aplikacja jest napisana.

>> --
>> Pancio
>>
> Nie wiem czego używasz do łączenia z bazą, ale ZEOSY mają coś takiego
> jak SQLmonitor i wszystkie zapytania SQL lądują w pliku.
> Może to jest dla ciebie, nie koniecznie w samej bazie.
Fajnie, tylko znowu odpowiadasz nie do końca na temat.
Wyłuskanie z takiego logu informacji o tym, że w interesującej nas
tabeli pole X zmieniło wartość na Y2 z wartości Y1, jest praktycznie
niemożliwe. Przy okazji to książkowa rzeźba w ... mule, imho.

--
wloochacz

Pogooglowalem troche, poczytalem i coraz bardziej dochodze do wniosku, ze obsluze to jednak z poziomu samej aplikacji tymbardziej, ze jeszcze jest taka mozliwosc.
Dla formalnosci podam, ze do laczenia sie z baza uzywam domyslego AnyDACa (teraz to FireDAC).
W glowie mam juz wstepnie ulozony plan dzialania, ale calkiem po prostu sadzilem, ze jest w samym silniku MS SQL (w wersji Express) mechanizm, ktory zrobi to za mnie z automatu. Jesli jest to niemozliwe, to sam oprogramuje odpowiednie zachowanie sie bazy na komendy Insert, Edit czy Delete.

--
Pancio

>> Nie wiem czego używasz do łączenia z bazą, ale ZEOSY mają coś takiego
>> jak SQLmonitor i wszystkie zapytania SQL lądują w pliku.
>> Może to jest dla ciebie, nie koniecznie w samej bazie.
> Fajnie, tylko znowu odpowiadasz nie do końca na temat.
Nie, pokazuję alternatywę. Wątkotwórca doszedł do wniosku że będzie to
robił w swojej aplikacji.

> Wyłuskanie z takiego logu informacji o tym, że w interesującej nas
> tabeli pole X zmieniło wartość na Y2 z wartości Y1, jest praktycznie
> niemożliwe. Przy okazji to książkowa rzeźba w ... mule, imho.
>
Tak, zgadzam się, co nie zmienia faktu że można.
Dodatkowo on nie będzie przecież robił tego co minutę a raz na
tydzień(analizowanie).
Więc teoretycznie można wychwytywać wiersze zawierające (postgres) ALTER
TABLE lub coś innego jeżeli chodzi o strukturę tabel.


Gorzej jeżeli chodzi o dane w poszczególnych polach.
Chociaż wtedy można wychwytywać wiersze z update.

W dniu 2017-07-11 o 08:50, Pancio pisze:
> Pogooglowalem troche, poczytalem i coraz bardziej dochodze do wniosku, ze obsluze to jednak z poziomu samej aplikacji tymbardziej, ze jeszcze jest taka mozliwosc.
Tak z ciekawości, a jaką możliwość masz na myśli?

> Dla formalnosci podam, ze do laczenia sie z baza uzywam domyslego AnyDACa (teraz to FireDAC).
> W glowie mam juz wstepnie ulozony plan dzialania, ale calkiem po prostu sadzilem, ze jest w samym silniku MS SQL (w wersji Express) mechanizm, ktory zrobi to za mnie z automatu. Jesli jest to niemozliwe, to sam oprogramuje odpowiednie zachowanie sie bazy na komendy Insert, Edit czy Delete.

W FD da się to zrobić bardzo ładnie, aż za ładnie.
Jest li tylko jeden wymóg - musisz pracować z włączonym CachedUdpates.

--
wloochacz

> > Pogooglowalem troche, poczytalem i coraz bardziej dochodze do wniosku, ze obsluze to jednak z poziomu samej aplikacji tymbardziej, ze jeszcze jest taka mozliwosc.
> Tak z ciekawości, a jaką możliwość masz na myśli?

W tym skrócie myślowym chodziło mi o to, że tak aplikacja, jak i sama baza jest na bardzo wczesnym etapie projektowania i wprowadzenie teraz jakiś zmian, nie stanowi dla mnie problemu.
Gorzej mam na przykład w swojej innej aplikacji, która IMO urosła już do całkiem pokaźnych rozmiarów. Kilka tygodni temu klient poprosił mnie, czy nie możnaby wprowadzić kilku zmian. Owszem, technicznie można zrobić niemal wszystko, ale nakład pracy jaki potrzeba w to włożyć jest nieporównywalnie większy, niż w projekcie, który aktualnie tworzę.

Ale jeśli już sobie "klikamy" to mam do Ciebie inne pytanie, ale też dotyczące MS SQL Express.
W moich aplikacjach, zwykłem używać jako Primary Key typu Int z ustawionym Identity Increment na wartość 1.
I teraz (jak dla mnie) ciekawostka. W wersji 2008 R2 silnika, wartość ta dodawana jest automatycznie co 1. Ale już w przypadku wersji silnika 2014 (2012 chyba też), po restarcie komputera z bazą danych licznik przeskakuje o wielkość rzędu 1000.
Czy można tego jakoś uniknąć, jednak z automatu, czyli bez generowania własnego licznika?

--
Pancio 

W dniu środa, 12 lipca 2017 09:05:59 UTC+2 użytkownik Pancio napisał:

> W moich aplikacjach, zwykłem używać jako Primary Key typu Int z ustawionym Identity Increment na wartość 1.
> I teraz (jak dla mnie) ciekawostka. W wersji 2008 R2 silnika, wartość ta dodawana jest automatycznie co 1. Ale już w przypadku wersji silnika 2014 (2012 chyba też), po restarcie komputera z bazą danych licznik przeskakuje o wielkość rzędu 1000.
> Czy można tego jakoś uniknąć, jednak z automatu, czyli bez generowania własnego licznika?

A czemu chcesz tego unikać? W sensie - w czym to przeszkadza?

To jest normalne zachowanie sql servera. W wersji 2012 dodali sekwencje (czytaj tutaj: https://www.codeproject.com/Tips/668042/SQL-Server-2012-Auto-Identity-Column-Value-Jump-Is).
Można to w sumie wyłączyć i sprowadzić do działania po staremu używając generatora sekwencji z opcji NO CACHE (czytaj tutaj: https://docs.microsoft.com/en-us/sql/t-sql/statements/create-sequence-transact-sql).

Osobiście jednak bym tego nie ruszał, bo o ile działało to w wersji 2012/2014 nie jestem przekonany czy kiedyś nie przestanie działać i tak czy tak będzie się trzeba przestawić na standardowe działanie sql servera.

pozdrawiam,
Przemek O.

W dniu środa, 12 lipca 2017 09:21:10 UTC+2 użytkownik immo napisał:
> W dniu środa, 12 lipca 2017 09:05:59 UTC+2 użytkownik Pancio napisał:
> 
> > W moich aplikacjach, zwykłem używać jako Primary Key typu Int z ustawionym Identity Increment na wartość 1.
> > I teraz (jak dla mnie) ciekawostka. W wersji 2008 R2 silnika, wartość ta dodawana jest automatycznie co 1. Ale już w przypadku wersji silnika 2014 (2012 chyba też), po restarcie komputera z bazą danych licznik przeskakuje o wielkość rzędu 1000.
> > Czy można tego jakoś uniknąć, jednak z automatu, czyli bez generowania własnego licznika?
> 
> A czemu chcesz tego unikać? W sensie - w czym to przeszkadza?

Czasami numerację rekordów pokazuję w aplikacji, aby użytkownik miał wgląd w numer rekordu. I już kilku userów zgłosiło mi, że nagle "zginęło im" 1000 rekordów. Dopiero po jakimś czasie doszukali się, że rekordów nikt nie usunął, tylko przeskoczyła numeracja.
Póki "na zewnątrz" nie widać numerów ID kolejnych wierszy, to spoko. Ale rzeczywiście jak wejdę w skórę typowego usera, to rozumiem jego rozczarowanie tym faktem.
Swoją drogą było dobrze, to po co było to zmieniać :)
Ale OK, przyjąłem do wiadomości, żeby nie ruszać tych sekwencji.

--
Pancio

W dniu środa, 12 lipca 2017 10:05:53 UTC+2 użytkownik Pancio napisał:

> Czasami numerację rekordów pokazuję w aplikacji, aby użytkownik miał wgląd w numer rekordu. I już kilku userów zgłosiło mi, że nagle "zginęło im" 1000 

I choćby z tego powodu nigdy tego nie robię :) ID jest wewnętrzną sprawą programu :P Jak chcesz mieć numerację dla człowieka to trzeba ją zrobić.

pozdrawiam,
Przemek O.

> > Czasami numerację rekordów pokazuję w aplikacji, aby użytkownik miał wgląd w numer rekordu. I już kilku userów zgłosiło mi, że nagle "zginęło im" 1000 
> 
> I choćby z tego powodu nigdy tego nie robię :) ID jest wewnętrzną sprawą programu :P Jak chcesz mieć numerację dla człowieka to trzeba ją zrobić.

A tak swoją drogą w jaki sposób to robisz? Trigery czy sam to obsługujesz z poziomu aplikacji? Bo chyba też będę musiał się z tym zmierzyć i szukam jakiegoś sprawdzonego, sprawnego rozwiązania.

--
Pancio

W dniu czwartek, 13 lipca 2017 13:13:17 UTC+2 użytkownik Pancio napisał:
> > > Czasami numerację rekordów pokazuję w aplikacji, aby użytkownik miał wgląd w numer rekordu. I już kilku userów zgłosiło mi, że nagle "zginęło im" 1000 
> > 
> > I choćby z tego powodu nigdy tego nie robię :) ID jest wewnętrzną sprawą programu :P Jak chcesz mieć numerację dla człowieka to trzeba ją zrobić.
> 
> A tak swoją drogą w jaki sposób to robisz? Trigery czy sam to obsługujesz z poziomu aplikacji? Bo chyba też będę musiał się z tym zmierzyć i szukam jakiegoś sprawdzonego, sprawnego rozwiązania.

Mówisz o logowaniu operacji?
Hmm... Ogólnie z poziomu aplikacji. Ale - ja nie koduje w sposób Click and Code :) Mam framework, gdzie definicje SQLi sobie siedzą np. w bazie, dana forma wie co ma obsługiwać. SQLe są obsługiwane przez odpowiednią klasę nimi zarządzającą. Przez co ma ona wiedzę o jej stanie przed i po aktualizacji i potrafi automatycznie logować to do np. bazy/ pliku / czy w jakiekolwiek inne miejsce. Core aplikacji ma też informacje o sesji, użytkownikach, uprawnieniach itd itp, więc log może być bardzo szczegółowy.

Gdybym tego nie miał to poszedł bym (jako że nie używam Expressa) w kierunku obsługi logów przez SQLServer - bo tak jest najprościej nie dotykając kodu.

Pytanie jest zawsze takie samo - chcesz zapłacić i się mniej narobić (kupując gotowe rozwiązanie, lepszą wersję SQLServera itd itp), czy zaoszczędzić (teoretycznie) i mieć więcej roboty tworząc swoje rozwiązanie.

pozdrawiam,
Przemek O.

W dniu 2017-07-13 o 13:33, immo pisze:
> W dniu czwartek, 13 lipca 2017 13:13:17 UTC+2 użytkownik Pancio napisał:
>>>> Czasami numerację rekordów pokazuję w aplikacji, aby użytkownik miał wgląd w numer rekordu. I już kilku userów zgłosiło mi, że nagle "zginęło im" 1000
>>>
>>> I choćby z tego powodu nigdy tego nie robię :) ID jest wewnętrzną sprawą programu :P Jak chcesz mieć numerację dla człowieka to trzeba ją zrobić.
>>
>> A tak swoją drogą w jaki sposób to robisz? Trigery czy sam to obsługujesz z poziomu aplikacji? Bo chyba też będę musiał się z tym zmierzyć i szukam jakiegoś sprawdzonego, sprawnego rozwiązania.
>
> Mówisz o logowaniu operacji?
Mowa chyba o nadawaniu numerków :)
Ja rozwiązałem to w ten sposób, że dostarczyłem nową funkcję do
preprocesora FireDAC, która jest wywoływana jako DefaultExpression
danego pola, które chce dostać nową wartość przy dodaniu rekordu.
Ta funkcja zwraca odpowiednią wartość i w ten sposób obsługuje ID i
numeratory - np. numer jakiegoś dokumentu.

> Hmm... Ogólnie z poziomu aplikacji. Ale - ja nie koduje w sposób Click and Code :) Mam framework, gdzie definicje SQLi sobie siedzą np. w bazie, dana forma wie co ma obsługiwać. SQLe są obsługiwane przez odpowiednią klasę nimi zarządzającą. Przez co ma ona wiedzę o jej stanie przed i po aktualizacji i potrafi automatycznie logować to do np. bazy/ pliku / czy w jakiekolwiek inne miejsce. Core aplikacji ma też informacje o sesji, użytkownikach, uprawnieniach itd itp, więc log może być bardzo szczegółowy.

To się da zrobić w FireDAC/AnyDAC by design, ale trzeba ciut niżej
zejść. Lepiej kod pokażę:
<code>
function TADAdaptedDataSetHelper.GetChangesAsXML: string;
var
   lXMLStorage  : TADStorage;
   lStringStream: TStringStream;
   lTable       : TADDatSTable;
   lEncoder     : TADEncoder;
begin
   lEncoder          := TADEncoder.Create(nil);
   //-- kododwanie XML dla typu danych XML w MSSQL musi być UTF-16!
   lEncoder.Encoding := ecUTF16;

   lTable        := Self.Table.GetChanges();
   lXMLStorage   := ADStorageManager().GetStorage('', sfXML,
Self.ResourceOptions, lEncoder);
   lStringStream := TStringStream.Create();
   try
     lXMLStorage.Open('', lStringStream, smWrite);
     lTable.SaveToStorage(lXMLStorage);
     lXMLStorage.Close;
     Result := lStringStream.DataString;
   finally
     lTable.Free;
     lXMLStorage.Free;
     lStringStream.Free;
     lEncoder.Free;
   end;
end;
</code>

Kod jest prosty nie wymaga tłumaczenia, raczej...
Warunek jest jeden - DataSet z którego pobieramy zmiany musi działać w
trybie CachedUpdates.
Natomiast sam XML zwraca dla każdego zmienionego wiersza jego stan przed
i po zmianach - wystarczy spojrzeć na tak wygenerowanego XMLa i wszystko
będzie jasne.
Można sobie tego XMLa sparsować i wydłubać z niego tylko np. zmiany.
Kod jest na tyle ogólny, że zadziała z dowolnym DataSetem.

> Gdybym tego nie miał to poszedł bym (jako że nie używam Expressa) w kierunku obsługi logów przez SQLServer - bo tak jest najprościej nie dotykając kodu.
Ale zdajesz sobie sprawę, że CDC to tylko w wersji Enterprise?
A ta wersja MSSQLa z definicji będzie tylko w bardzo dużych organizacjach...

> Pytanie jest zawsze takie samo - chcesz zapłacić i się mniej narobić (kupując gotowe rozwiązanie, lepszą wersję SQLServera itd itp), czy zaoszczędzić (teoretycznie) i mieć więcej roboty tworząc swoje rozwiązanie.
Mam zupełnie inną opinię w tej kwestii.
Żaden gotowiec po stronie bazy danych nie da Ci wszystkiego, co jest
potrzebne Twojej aplikacji.
No chyba, ze ta aplikacja jest prosta i realizuje dostęp do danych
table-by-table - to może, ale i to nie zawsze...

Jest jeszcze inne podejście, po bandzie - ale to wymaga zmiany podejścia
do programowania o 180 stopni ;-)
http://blog.synopse.info/post/2014/06/22/Audit-trail-for-ORM-change-tracking

--
wloochacz

W dniu czwartek, 13 lipca 2017 18:23:04 UTC+2 użytkownik wloochacz napisał:
> W dniu 2017-07-13 o 13:33, immo pisze:
> > W dniu czwartek, 13 lipca 2017 13:13:17 UTC+2 użytkownik Pancio napisał:

> > Mówisz o logowaniu operacji?
> Mowa chyba o nadawaniu numerków :)
> Ja rozwiązałem to w ten sposób, że dostarczyłem nową funkcję do 
> preprocesora FireDAC, która jest wywoływana jako DefaultExpression 

A ja mam to (że tak powiem) gdzieś. Nie przeszkadza mi nadawanie ID przez SQL Server. Nigdzie nikomu tego nie pokazuje, a programowi to bez różnicy czy idzie to po kolei czy skacze z numeracją :)

> To się da zrobić w FireDAC/AnyDAC by design, ale trzeba ciut niżej 
> Kod jest prosty nie wymaga tłumaczenia, raczej...
> Warunek jest jeden - DataSet z którego pobieramy zmiany musi działać w 
> trybie CachedUpdates.

Pewnie że tak, ale po pierwsze jak piszesz wymagane CachedUpdates, po drugie czasami ciężko coś zmienić jak się ma kobyłę która w sumie działa poprawnie :)

> Ale zdajesz sobie sprawę, że CDC to tylko w wersji Enterprise?
> A ta wersja MSSQLa z definicji będzie tylko w bardzo dużych organizacjach...

Dlatego też zaznaczyłem że mówię o sobie i "moich" klientach:)


> Mam zupełnie inną opinię w tej kwestii.
> Żaden gotowiec po stronie bazy danych nie da Ci wszystkiego, co jest 
> potrzebne Twojej aplikacji.

Ależ oczywiście zgadzam się z Tobą. W domyśle zawsze jest dostosowanie tego do własnych potrzeb. Pytanie tylko czy warto pisać takie coś od zera, czy kupić coś co działa i zmodyfikować. To też w sumie zależy od potrzeb.
Ja w każdym razie już oduczyłem się pisania wszystkiego od zera :P

> Jest jeszcze inne podejście, po bandzie - ale to wymaga zmiany podejścia 
> do programowania o 180 stopni ;-)
> http://blog.synopse.info/post/2014/06/22/Audit-trail-for-ORM-change-tracking

Panie - ja do mORMota próbuje podejść już od roku. Ale nie wiem, z jednej strony jakoś mnie to odrzuca, z drugiej trochę nie mam czasu żeby przebić się przez dokumentacje. Niemniej widzę potencjał tego rozwiązania i kilka ciekawych rozwiązań które by się u mnie sprawdziły. Przydała by się pozycja "mORMot dla idiotów"... albo Twój wykład na ten temat na zlocie :P

pozdrawiam,
Przemek O.

W dniu 2017-07-14 o 09:17, immo pisze:
/ciach/

>> Jest jeszcze inne podejście, po bandzie - ale to wymaga zmiany podejścia
>> do programowania o 180 stopni ;-)
>> http://blog.synopse.info/post/2014/06/22/Audit-trail-for-ORM-change-tracking
>
> Panie - ja do mORMota próbuje podejść już od roku. Ale nie wiem, z jednej strony jakoś mnie to odrzuca,
Miałem podobnie, jednakże zweryfikowałem swoje podejście i wcale nie
jest tak jak, mi się wydawało.
Człowiek pisze inaczej niż ja, ale to wcale nie znaczy że gorzej;
brutalna prawda jest taka, że miejscami to mogę za nim co najwyżej
czapkę nosić ;-)

> z drugiej trochę nie mam czasu żeby przebić się przez dokumentacje. Niemniej widzę potencjał tego rozwiązania i kilka ciekawych rozwiązań które by się u mnie sprawdziły. Przydała by się pozycja "mORMot dla idiotów"... albo Twój wykład na ten temat na zlocie :P
mORMot jest zajebisty!
No, miejscami nie jest, ale to i tak nie wyklucza jego zajebistości ;-)

Co do wykładu - ja znam na tej grupie co najmniej dwie osoby, które z
mORMota są znacznie lepiej, dalej i naj ode mnie (piszę do Kolegów Adama
i Jacka).
Zatem ze względu na brak czasu własnego i mało czasu do zlotu z wykładem
się nie odważę.
Wolałbym, żeby taki wykład zrobili Koledzy Adam/Jacek lub sam Autor ;-)

--
wloochacz