GoldenLine
Zaloguj się
Mariusz Siemiński

Mariusz Siemiński Konsultant ds. IT,
Be TSE

Temat: WF-MAG migracja serwera z upgrade'em SQL Servera

Usiłujemy zrobić migrację serwera WF-MAG z:
Windows 2008 + SQL Server 2008 R2
na
Windows 2012 R2 + SQL Server 2014

Według dokumentacji i innych wątków na tym forum migracja pomiędzy sql 2008 R2 i 2014 powinna być kompatybilna??

Sama migracja się udała, jednak po jakimś czasie okazało się, że nie da się dodać nowego kontrahenta z powodu błędu:
"Automatyczne nadanie numeru nie powiodło się. Powód: Nie można wstawić wiersza zduplikowanego klucza w obiekcie dbo.kontrahent o unikatowym indeksie KONTRAHENT_KOD. Wartości zduplikowanego klucza to (1,0). (2300) Czy ponowić próbę?
Ewidentnie jest problem z wyliczanie kolejnego wolnego ID. Zamiast XXX aplikacja próbuje dodać ponownie kontrahenta o ID = 0.
Problem został zgłoszony do pomocy technicznej. Kazali odpalić poprawkę z pliku gen_guid_nowy.zip. Kompletnie niczego to nie zmieniło. Dodatkowo sprawdziłem i poprawka w ogóle nie sprawdza tabeli kontrahent tylko bodajże artykuł.

I na koniec pytanie. Czy taka migracja oby na pewno jest wspierana. Jeśli tak, to może trzeba wykonać jakieś dodatkowe kroki? Czy ktoś miał już podobny problem przy takiej migracji?

Chciałbym uniknąć upgrade'u sql'a na starym serwerze, bo potem nie ma już odwrotu i jak nie zadziała prawidłowo po aktualizacji to zostaniemy bez WF-Mag'a :( Piszę z doświadczenia bo raz już tak było - przy migracji z 2005. Nasza wina bo trzeba było to zrobić z wersją pośrednią 2008 R2. No i teraz mamy tą wersję pośrednią, ale nadal wygląda na to że na 2014 aplikacja nie działa prawidłowo.

Z góry dziękuję za każdą poradę.
Link do wypowiedziLink
Krzysztof Stachyra

Krzysztof Stachyra Szef Wydziału
Produkcji Systemów
Handlowo-Magazynowyc
h i ...

Temat: WF-MAG migracja serwera z upgrade'em SQL Servera

Panie Mariuszu opisywany problem nie odnosi się do procesu migracji a do problemu w danych na tabeli kontrahent.
Poprawka generowania guid tu nic nie pomoże bo jak Pan zauważył dotyczy ona towarów, nie znam kontekstu korespondencji/rozmowy więc nie wiem dlaczego akurat taka została zalecona.
Proszę zajrzeć do tabeli kontrahent do kolumny KOD - na czystej bazie kontrahent systemowy Sprzedaż detaliczna ma wartość 1 i kolejni kontrahenci są numerowani max+1 jeśli tu jest jakiś null albo inne śmieci to pewnie dlatego funkcja podstawia 0 za null i próbuje wstawiać 1 - trzeba uporządkować tą kolumnę.

Odpowiadając wprost na pytanie - migracja jest wspierana i dopuszczalna bo działa w kontekście 3 wersji SQL
Link do wypowiedziLink
Mariusz Siemiński

Mariusz Siemiński Konsultant ds. IT,
Be TSE

Temat: WF-MAG migracja serwera z upgrade'em SQL Servera

Dziękuję za odpowiedź, jednak nie do końca mam klarowny obraz sytuacji. Jeszcze raz:
1. WF-MAG działa prawdiłowo na starym serwerze.
2. Robimy archiwizację,
3. przegrywamy backup na nowy serwer,
4. robimy dearchiwizację.
5. Wprowadzanie nowego kontrahenta nie działa.

Jeśli byłby błąd na poziomie struktur danych / wierszy w tabeli to błędy były by na obydwu środowiskach, a są tylko na nowym.

Jakieś pomysły?
Link do wypowiedziLink
Rafał M.

Rafał M. Dyrektor ds. Asseco
WAPRO ERP, Asseco
Business Solutions
...

Temat: WF-MAG migracja serwera z upgrade'em SQL Servera

Jaka to jest wersja programu WF-Mag?
Link do wypowiedziLink
Mariusz Siemiński

Mariusz Siemiński Konsultant ds. IT,
Be TSE

Temat: WF-MAG migracja serwera z upgrade'em SQL Servera

8.11
Link do wypowiedziLink
Rafał M.

Rafał M. Dyrektor ds. Asseco
WAPRO ERP, Asseco
Business Solutions
...

Temat: WF-MAG migracja serwera z upgrade'em SQL Servera

Wersja kompatybilna z SQL 2014 - proszę upewnić się, że po migracji wszystkie triggery na tabeli KONTRAHENT są włączone. Proszę też zweryfikować czy tabele i indeksy nie są uszkodzone - za pomocą DBCC CHECKDB
Link do wypowiedziLink
Mariusz Siemiński

Mariusz Siemiński Konsultant ds. IT,
Be TSE

Temat: WF-MAG migracja serwera z upgrade'em SQL Servera

Wszystkie triggery są włączone,
Jeśli chodzi o indeksy to za pierwszym podejściem zostały one nawet zrebuildowane, celem optymalizacji wydajności:
Alter TABLE XXXX INDEX ALL REBUILD

Niestety niczego to nie zmienia.
Tak na prawdę to do znalezienia błędu prawdopodobnie potrzebna będzie wiedza, jak dokładnie aplikacja wylicza następny kod kontrahenta, próbowałem to stwierdzić za pomocą SQL Profilera, ale niestety nie udało mi się namierzyć konkretnego zapytania (w stylu: select max(KOD_KONTRAHENTA) from KONTRAHENT). Musi to być robione jakimś innym mechanizmem, albo procedurą który/a ewidentnie sobie nie radzi na tym nowym serwerze.

Na czwartek planujemy kolejne podejście tym razem chyba przy online'owym wsparciu supportu, zobaczymy.

Dziękuję za rady. Jeśli jest coś jeszcze co możemy sprawdzić, proszę o informację
Link do wypowiedziLink
Rafał M.

Rafał M. Dyrektor ds. Asseco
WAPRO ERP, Asseco
Business Solutions
...

Temat: WF-MAG migracja serwera z upgrade'em SQL Servera

Kod kontrahenta wylicza trigger tiw_kontrahent. Skoro jest włączony to jeszcze proszę sprawdzić pulę kont księgowych (czwarta zakładka na formularzy edycji danych firmy) i zmodyfikować wartość ostatnio nadanego numeru (zwiększając np. o 1).
Link do wypowiedziLink
Mariusz Siemiński

Mariusz Siemiński Konsultant ds. IT,
Be TSE

Temat: WF-MAG migracja serwera z upgrade'em SQL Servera

Temat robi się coraz ciekawszy.

Odczytałem tego triggera i sprawdziłem ręcznie kod - działa prawdiłowo. Niestety jeden prosty insert testowy:
INSERT INTO KONTRAHENT
((...)) VALUES
(5707,0,'',1,0,NULL,NULL,0,'nowy kontrahent (5707)','',0,0,NULL,NULL,0,'',0,0,0,0,'',0,0,'','','','',0,0,0,0,'',NULL,NULL,'','','',0,'','','','','','','','','',3000008,1,0,'','','','','Dowód osobisty',NULL,NULL,'','','','','',NULL,NULL,NULL,NULL,NULL,0,0,0,0,0,0,'',0,0,0,0,0,0,0,0,'',0,'',0,0,NULL,NULL,0,NULL,NULL,NULL)

odpala chyba jeszcze kilka różnych innych triggerów, być może rekurencyjnie, a na pewno co najmniej tdw3_kontrahent i przy nim pojawia się ciekawy komunikat:
(0 row(s) affected)
Msg 102, Level 15, State 1, Procedure tdw3_kontrahent, Line 29
Incorrect syntax near '@errno'.

I teraz po przeprowadzeniu małego śledztwa okazuje się że od wersji SQL 2012 składnia RAISERROR się zmieniła i cytuję:
------------------------------------------------------------------------------------------------------------------------
SQL 2012 does not support the undocumented version of Raiserror The supported syntax is
RAISERROR(@Message,Serverity,state);
-- @Message could be message id , but it should exist in sysmessages, so if you want to send custom messages, I think you should add them sysmessages
http://msdn.microsoft.com/en-us/library/ms178592.aspx
Or the other option is to use THROW
http://technet.microsoft.com/en-us/library/ee677615.aspx
----------------------------------------------------------------------------------------------------------------------
Niestety we wszystkich tych triggerach znajduje się następujący kod:
raiserror @errno @errmsg
który powoduje błędy, co może skutkować w ogóle nie mającymi nic wspólnego z rzeczywistością komunikatami w interfejsie aplikacji

Pytam zatem ponownie:
Czy aby na pewno wersja 8.11 wspiera SQL 2012+ (w szczególności 2014), a jeśli tak to jakim cudem trigery które są w niej zawarte, posiadają kawałki kodu kompletnie nie kompatybilne z tymi wersjami?

Niezależnie od powyższego, co mamy z takim fantem zrobić? Bo wydaje mi się, że śledztwo dotyczące samej tabeli kontrahent, chyba nie ma na tym etapie sensu, bo problem wydaje się szerszy.

P.S. Po zmianie w tiw_kontrahent oraz tdw3_kontrahent linijek:
raiserror @errno @errmsg
na
raiserror (@errmsg,16,@errno) - wiem że @errno w tym przypadku nie ma większego sensu
..kontrahenta dodaje się bez żadnego problemu!!! :)

Ponownie z góry dziękuję za wszelkie sugestie
Link do wypowiedziLink
Rafał M.

Rafał M. Dyrektor ds. Asseco
WAPRO ERP, Asseco
Business Solutions
...

Temat: WF-MAG migracja serwera z upgrade'em SQL Servera

Jeżeli te triggery zawierają kod nie wspierany prze SQL 2012 to znaczy, że w bazie danych jest lub był kiedyś zainstalowany program w starszej wersji ( inny niż WF-Mag) i nie został zaktualizowany.
Kiedy przygotowywaliśmy programy do zgodności z SQL 2012 informowaliśmy klientów i partnerów w biuletynach oraz na stronie internetowej, że muszą najnowszymi wersjami zaktualizować wszystkie programy zainstalowane w bazie danych - bez znaczenia czy aktualnie z nich korzystają czy nie oraz czy instalowali tylko jako demo. Należało to zrobić przed migracją wtedy proces przechodzi bezboleśnie. Trigerry, o których piszemy są wspólne dla kilku programów, które korzystają z tabeli kontrahent i każdy z tych programów musi być zaktualizowany.

Teraz gdy wiemy o co chodzi zachęcam do kontaktu z serwisem i przedstawienie problemu - po migracji bazy będzie trudniej ale rozwiązanie się znajdzie.

Nawiasem mówiąc SQL Server nie kontroluje podczas dearchiwizacji czy zawartość bazy danych jest zgodna z jego wersją i dlatego takie błędy wychodzą dopiero podczas używania programu.
Link do wypowiedziLink
Mariusz Siemiński

Mariusz Siemiński Konsultant ds. IT,
Be TSE

Temat: WF-MAG migracja serwera z upgrade'em SQL Servera

Dziękuje za wszystkie rady, jestem już w kontakcie z supportem. Prawdopodobnie (mam nadzieję) problem powoduje nieużywany (ale zainstalowany) program WF-Analizy.
Będę dzisiaj robił jego aktualizację i trzymam kciuki, że po jej zakończeniu triggery zaczną wyglądać poprawnie.

Jeszcze raz dzięki.
Link do wypowiedziLink
Krzysztof Stachyra

Krzysztof Stachyra Szef Wydziału
Produkcji Systemów
Handlowo-Magazynowyc
h i ...

Temat: WF-MAG migracja serwera z upgrade'em SQL Servera

Analizy na pewno nie są powodem ponieważ one nie zakładają triggerów - są programem czytającym dane a nie zapisującym a już na pewno nie na kluczowych kartotekach.
W administratorze baz danych po wybraniu opcji Pokaż informacje o bazie dostanie Pan konkretną informację jakie są struktury i w jakich wersjach.
Link do wypowiedziLink
Mariusz Siemiński

Mariusz Siemiński Konsultant ds. IT,
Be TSE

Temat: WF-MAG migracja serwera z upgrade'em SQL Servera

W administratorze wyświetla się jedynie WF-MAG 8.11.0.
Jeśli zatem nie jest to z winy Analiz to winne musiałby być skrypty aktualizujące struktury danych przy którymś z wielu update'ów. Mamy tą aplikację od bardzo bardzo dawna i ciężko mi stwierdzić ile update'ów już było przeprowadzonych, ale myślę że co najmniej kilkanaście.

Wychodzi na to że któryś update nie wykonał się poprawnie. Około 2 lat temu mieliśmy z jakimś update'em problem i z tego co pamiętam baza została aktualizowana ręcznie (odpłatnie!!) przez pracowników serwisu. być może wtedy coś zostało popsute.

Póki co doświadczenia z działem serwisu są co najmniej słabe. Cały dzień mailowania nie przyniósł praktycznie żadnego efektu ani nawet postępu. Próbowałem najpierw wyjaśnić kwestię przez telefon, ale chyba nikt mnie nie zrozumiał (rozumiem że problem jest nietypowy), więc otrzymałem informację  że mam się kontaktować mailowo.

Nie jestem w stanie zrozumieć, że nie ma skryptu / zestawu skryptów / binarki /instalatora - jak go zwał tak go zwał, który zresetował by wszystkie procedury/triggery/funkcje do domyślnej dla danej wersji formy nie ruszając przy tym samych danych.
Link do wypowiedziLink
Krzysztof Stachyra

Krzysztof Stachyra Szef Wydziału
Produkcji Systemów
Handlowo-Magazynowyc
h i ...

Temat: WF-MAG migracja serwera z upgrade'em SQL Servera

Ale czym dla Pana jest domyślna wersja? Jak skrypt ma zaktualizować coś, skoro nawet Pan nie wie co na tej bazie było instalowane?
Tak jak Rafał Panu pisał, przy przechodzeniu pomiędzy poszczególnymi wersjami - KAŻDY PROGRAM, który był na bazie zainstalowany i był potem aktualizowany poprawiał definicję tego obiektu tak aby nie była ona problematyczna. Obiekty są szyfrowane w bazie i nie ma prostej metody typu plug&play uruchom i sobie popraw - programista poprawia obiekty w określonej wersji i tylko te (nie rusza nigdy obiektów użytkownika, które także w bazie mogą się pojawić).

Proces aktualizacji uruchamiany przez administratora bazy danych jest transakcyjny - jeśli coś się nie powiedzie przy przejściu pomiędzy poszczególnymi wersjami to aktualizacja jest wycofywana do ostatniej działającej wersji.
Link do wypowiedziLink
Mariusz Siemiński

Mariusz Siemiński Konsultant ds. IT,
Be TSE

Temat: WF-MAG migracja serwera z upgrade'em SQL Servera

krótko: wersja domyślna to taka, która powinna działać z daną aplikacją, kropka.
Nie ja nie wiem, tylko wasza aplikacja najwyraźniej nie wie. Moim zdaniem od początku nie było tam zainstalowane kompletnie nic oprócz WF-MAG'a, który to powinien się sam zupgrade'ować, a ten wątek nigdy nie powinien powstawać.

Właśnie nie rozumiem, po co te obiekty są szyfrowane, odszyfrowanie to żaden problem, tylko trzeba się bez sensu namęczyć. Poza tym nie trzeba ich odszyfrowywać. Po prostu wystarczy je nadpisać - problem z głowy.

Aktualizacja nie jest transakcyjna, przynajmniej nie zawsze była. Wiem, bo wywalała nam się w trakcie update'u, dlatego właśnie wymagana była ingerencja Waszego pracownika
Link do wypowiedziLink
Krzysztof Stachyra

Krzysztof Stachyra Szef Wydziału
Produkcji Systemów
Handlowo-Magazynowyc
h i ...

Temat: WF-MAG migracja serwera z upgrade'em SQL Servera

Panie Mariuszu - zadam proste pytanie - ile aplikacji napisał Pan w swoim życiu?

Tok rozumowania jaki Pan opisuje jest błędny i niezgodny z prawdą a przy okazji miesza Pan troszkę pojęcia.

Operacja wgrania domyślnej wersji jak to Pan sobie ładnie ujął nazywa się w administratorze baz danych Aktualizuj bazę do wersji X.XX.X - jeśli baza jest zmieniona to wymuszenie ponownej aktualizacji nadgrywa te zmiany znowu tym co przyszło w danej wersji.
Problem w tym, że Pan pomija cały czas istotny fakt - NIE ZROBILIŚCIE PAŃSTWO AKTUALIZACJI BAZY DANYCH NA SERWERZE 2008 DO WERSJI ZGODNEJ Z NOWSZYM SQL.
Informowaliśmy naszych klientów o tym zarówno w mailingach jak i przez pulpit informacyjny - konkretny link do tej informacji
http://www.wapro.pl/aktualnosci-aplikacja/koniec-wspar...
o ile mnie pamięć nie myli to było też na głównej stronie i powtarzane było to kilkukrotnie.
W związku z powyższym problem nie dotyczy jak Pan ujmuje kompatybilności wersji tylko tego, że zmigrowane zostały obiekty do nowego SQL, które nie są z nim kompatybilne i problem dotyczy SQL a nie wersji WF-Mag.

Obiekty są szyfrowane po to, żeby byle pierwszy programista nie poprawiał logiki programu samodzielnie a potem nie zgłaszał się do serwisu, że program działa błędnie - było wiele takich przypadków i kończyło się to zazwyczaj katastrofą bo wiedza programisty okazywała się mizerna i brał się za zagadnienia o których nie miał pojęcia.

Odsyłam Pana do wikipedii co oznacza pojęcie TRANSAKCYJNA i model ACID - transakcyjna nie oznacza, że nie może wystąpić błąd w jej trakcie tylko tyle, że jeśli ten błąd wystąpi to program wycofa bezpiecznie wgrane w połowie modułu do ostatniej dobrej wersji tak żeby klient mógł uruchomić program na określonej wersji - oczywiście jeśli aktualizacja była przez kilka wersji to nie oznacza, że ta po wycofaniu będzie tą od której klient rozpoczął proces tylko może być to ostatnia do której udało się proces przeprowadzić.

Ale merytorycznie jeśli oczekuje Pan wsparcia to proszę postępować zgodnie z ich wskazówkami bo na forum na pewno Pan tego problemu nie rozwiąże a wymiana zdań tylko po to żeby sobie uprzykrzać życie nie ma najmniejszego sensu i nie przybliży Pana do sukcesu.
Link do wypowiedziLink
Mariusz Siemiński

Mariusz Siemiński Konsultant ds. IT,
Be TSE

Temat: WF-MAG migracja serwera z upgrade'em SQL Servera

Panie Krzysztofie
Akurat napisałem w swoim życiu kilkaset tysięcy linii kodu aplikacyjnego, włącznie z aplikacjami bazodanowymi i w językach stricte bazodanowych jak transact i plsql.

To Pan pomija fakt, że:
ZROBILIŚMY AKTUALIZACJĘ BAZY DANYCH NA SERWERZE 2008!!!!!!
Na serwerze Win 2008+SQL Server2008R2 zrobiliśmy upgrade do WF-MAG 8.11. dopiero PO tym fakcie przenieśliśmy bazę (archiwizacja/dearchiwizacja) na "wpieraną" wersję 2012/2014 i odbiliśmy się od ściany, bo nie dało się utworzyć nowego kontrahenta!

Od samego początku piszę o problemie z MIGRACJĄ nie z AKTUALIZACJĄ, więc proszę czytać ze zrozumieniem.

To były WASZE sugestie, że jakiś komponent Waszej aplikacji nie został zaktualizowany, ale im dalej w to brniemy tym bardziej wydaje mi się to hipotezą błędną.

Cały zatem Pański akapit:
"W związku z powyższym problem nie dotyczy jak Pan ujmuje kompatybilności wersji tylko tego, że zmigrowane zostały obiekty do nowego SQL, które nie są z nim kompatybilne i problem dotyczy SQL a nie wersji WF-Mag." - nie ma kompletnie żadnego sensu

Co do szyfrowania, widać nie jestem byle pierwszym programistą, bo nie dość że je odszyfrowałem to jeszcze znalazłem w nich błędy, które powodują problem z którym się do was ZGŁOSIŁEM, żeby nie spowodować innych problemów przez samodzielne poprawki.

Co do transakcyjności to upgrade z wersji 7.71.8 do 7.72 się - z braku innego słowa - "WYWALAŁ" i żadnego rollback'u tam nie było. Po szczegóły proszę się zgłosić do zgłoszenia serwisowego.

Co do współpracy z serwisem to bzdury zasugerowane przy pierwszym kontakcie, spowodowały że spróbowałem szczęścia na tym forum. Aktualnie jednak sytuacja wygląda bardzo obiecująco.

...więc bardzo dziękuje za wszelkie sugestie, w szczególności pana Rafała, które pozwoliły na namierzenie problemu z triggerami.
Panu natomiast życzę wielu sukcesów i zadowolenia z życia, oraz grona wielu znajomych przed którymi będzie mógł Pan błyszczeć swoją niewątpliwą nieomylnością.
Link do wypowiedziLink
Krzysztof Stachyra

Krzysztof Stachyra Szef Wydziału
Produkcji Systemów
Handlowo-Magazynowyc
h i ...

Temat: WF-MAG migracja serwera z upgrade'em SQL Servera

Nikt nie błyszczy nieomylnością (jeśli Pan to tak odebrał to przepraszam i śpieszę z wyjaśnieniem), próbuje Panu rzeczowo objaśnić proces funkcjonowania aplikacji, ale Pan dalej obstaje przy swoim.

Powtórzę jeszcze raz - proces aktualizacji jest transakcyjny na poziomie aplikacji (administratora bazy danych), mogę to potwierdzić po wielokroć w liczbie X wykonanych testów i zasymulować Panu przypadek testowy aby Pan zrozumiał jak działa ten mechanizm. Więc, powtórzę jeszcze raz jeśli aktualizacja się wywali (z jakiegokolwiek powodu) to zmiany do poszczególnej wersji w bazie nie są zapisane i automatycznie baza nie jest oznaczona jako pracująca w wersji, do której nie została zaktualizowana. Inaczej sytuacja ma miejsce jeśli ktoś wziąłby skrypt aktualizujący i uruchomił go z poziomu mgm studio ale najpierw musiałby mieć źródła pliku WF2 - więc z całą pewnością zakładam, że to raczej nie ten przypadek.

Ze zrozumieniem czytam tylko jak Pan widzi proces migracji (przejście z SQL do SQL) poprzez dearchiwizację zakończył się prawidłowo, a błąd poruszany w tym wątku jest pokłosiem procesu AKTUALIZACJI a nie migracji. Migracja go tylko i wyłącznie uwydatniła, że po aktualizacji z jakiegoś powodu dalej jest obiekt nie w takiej wersji jak być powinien - dlaczego tu to się objawiło wyjaśnił Rafał, dlatego, że proces dearchiwizacji nie analizuje obiektu do momentu jego wykonania czyli dla triggera uruchomienia zdarzenia na tabeli źródłowej.
Proszę ponownie przeczytać ostatni akapit Pana pierwszego postu, absolutnie nie wynika z niego na jakiej wersji była robiona aktualizacja.

W procesie migracji wersji wszystkie triggery były nadpisywane w składni zgodnej z określoną wersją, robione były testy w dziale testów i serwis wielokrotnie pomagał klientom z migracją takich baz, których właśnie wybrane moduły nie były aktualizowane.
Pytanie zatem do Pana czy po wykonaniu aktualizacji na serwerze źródłowym baza pracowała jeszcze przez jakiś czas czy od razu po aktualizacji na nim była przeprowadzona migracja? Jeśli baza pracowała to pytanie czy przypadkiem nie była wgrana jeszcze jakaś poprawka z innego powodu, której składnia była stara (na nowym serwerze nie było by to możliwe).

Jeżeli pisał Pan kod i chce Pan go poprawić to nie ma problemu, może Pan odszyfrować sobie wszystkie triggery i poprawić składnię samodzielnie - ten rodzaj składni występuje tylko w triggerach - oczywiście należałoby go poprawić aby faktycznie coś tam zwracał w większości przypadków to jest @msg,16,1 - ostrzegam tylko, że nie wszystkie obiekty zawsze da się odszyfrować, z niektórymi narzędzia do deszyfracji sobie nie radzą i wtedy problem może wyjść w jakimś innym egzotycznym miejscu.
Jeśli nie chce Pan tego robić samodzielnie to zapewne z pomocą serwisu się uda bo już ten temat był za mną konsultowany.

Nie mniej jednak, życzę szybkiego rozwiązania problemu i na przyszłość podaję uproszczoną instrukcję jak można sobie poradzić z takimi dziwnymi aktualizacjami.
1. Przed aktualizacją robimy kopię bazy danych oraz kopię programu (folder binarek w program files)
2. Odtwarzamy bazę danych pod inną nazwą
3. Instalujemy sobie nową wersję programu
4. Wykonujemy aktualizację kopii bazy danych do nowej wersji
5. robimy testy
6. jeśli jest ok to robimy upgrade bazy produkcyjnej
7. Jeśli jest źle to kasuje Pan bazę testową, przywraca Pan binarki wf-mag do oryginalnej wersji - trzeba pamiętać, że program ma też moduły wspólne w program files\common files\wapro np. epoczta, edokumenty i je też należy zachować w odpowiedniej wersji jako kopię jeśli coś pójdzie nie tak to je przywrócić

Ta metoda pozwoli Panu w przyszłości zawsze po nieudanej aktualizacji przywrócić stan z przed aktualizacji i przełożyć ją na inny czas nie blokując pracy użytkowników.
Link do wypowiedziLink
Mariusz Siemiński

Mariusz Siemiński Konsultant ds. IT,
Be TSE

Temat: WF-MAG migracja serwera z upgrade'em SQL Servera

Bardzo dziękuję za fachową wypowiedź.
Nie będę wracał do transakcyjności, bo myślę, że to był jakiś wyjątkowo nietypowy przypadek, poza tym miało to miejsce kilka lat temu więc nie ma co do tego teraz wracać.

Dziękuję również za podpowiedź jeśli chodzi o proces testowania nowej wersji. Generalnie nie potrzebujemy aktualnie takiego typu rozwiązania, ponieważ robię to tak:
1. Instaluję nową wersję tylko na serwerze sql.
2. backup
3. upgrade bazy danych (struktur)
4. w razie problemów dearchiwizacja
5. użytkownicy pracują normalnie na swojej starej / poprzedniej wersji
6. binarki na serwerze czekają na ewentualne poprawki / sugestie serwisu i kolejną próbę aktualizacji.
7. aktualizacja zakończona sukcesem
8. aktualizacja binarek na stacjach klienckich
Wydaje mi się że to wystarczy, chyba że z czegoś nie zdaję sobie sprawy??

W tym konkretnym przypadku aktualizacja była robiona około 2 miesięcy temu, do wersji 8.11.
Jako że ta wersja miała współpracować z nowymi wersjami SQL'a, to w między czasie na oddzielnym sprzęcie szykowaliśmy nowy serwer 2012 R2 + sql 2014.

Przez ten czas nie zaobserwowaliśmy żadnych problemów z działaniem aplikacji. Nie były również wykonywane żadne dodatkowe upgrade'y. Nigdy też ręcznie niczego tam nie poprawialiśmy, ewentualnie uruchamialiśmy gotowe poprawki dostarczone przez serwis, ale to wspomniane dawne czasy.

Po 2 miesiącach i przygotowaniu nowego serwera, przeprowadziliśmy "pomyślną" procedurę migracji:
1. archiwizacja na starym serwerze
2. instalacja binarek w tej samej wersji 8.11 na nowym serwerze
3. dearchiwizacja
4. uruchomienie aplikacji lokalnie na serwerze wstępne testy - aplikacja działa poprawnie
5. godzinne testy użytkowników (bez dodawania kontrahenta) - potwierdzili poprawne działanie podstawowych, najczęściej używanych elementów - sukces
6. użytkownicy wznowili normalną pracę.
7. następnego dnia przy dodawaniu nowego kontrahenta pojawił się błąd.
8. Powrót do pracy w całości na starym serwerze, bez jakiegokolwiek kolejnego odtwarzania danych - wszystkie nowo wprowadzone przez1,5 dnia faktury i zmiany zostały stracone, ale woleliśmy nie ryzykować odtwarzania potencjalnie popsutej bazy na źródłowym serwerze, na którym do tej pory wszystko działało OK.

Dalszy ciąg Pan zna.
Jeśli po tym wyjaśnieniu, cokolwiek jeszcze przychodzi Wam do głowy, co mogło by pomóc w diagnozie i rozwiązaniu problemu, to proszę o informację. Póki co aktualny plan (rozważany przez serwis) uwzględnia ręczne nadpisanie problematycznych triggerów wersjami aktualnymi. Triggerów, które z jakiegoś powodu automatycznie nie zostały uaktualnione, chociaż, co sprawdziłem, ich data modyfikacji zgadza się z datą upgrade'u do 8.11, więc można powiedzieć że zostały nadpisane, ale swoimi starymi wersjami.
Wolałbym jednak załatwić to kompleksowo - czyli na wszelki wypadek uaktualnić wszystkie triggery/funkcje/procedury, żeby się nie okazało, że uaktualnimy 2 triggery a gdzieś w innych miejscach zostanie ich jeszcze X i będą niejawnie powodować inne błędy, które mogą w przyszłości spowodować większe lub mniejsze problemy.

Przychodzi mi jeszcze jedna rzecz do głowy. Nie byłem świadomy takiej funkcjonalności, ale z Pana wypowiedzi wywnioskowałem, że operację aktualizacji można wykonać jeszcze raz z poziomu Administratora... Może warto spróbować to zrobić, aby się upewnić czy m.in. te triggery zostaną zmienione i ewentualnie sprawdzić na co. Wtedy przynajmniej będzie pewność, czy aktualizacja je tak na prawdę aktualizuje. Jeśli nie, to będzie wiadomo, że należy szukać tego przyczyny i tylko i wyłącznie na tym się skupić. Po wyeliminowaniu blokujących update czynników, wszystko powinno wtedy wrócić do normy i wstępnie zagwarantować również sukces kolejnych upgarde'ów, m.in. oczekującego już 8.20.

Podkreślę jeszcze raz - aktualnie cały czas baza działa produkcyjnie na starym serwerze 2008 R2Ten post został edytowany przez Autora dnia 22.10.16 o godzinie 20:44
Link do wypowiedziLink
Krzysztof Stachyra

Krzysztof Stachyra Szef Wydziału
Produkcji Systemów
Handlowo-Magazynowyc
h i ...

Temat: WF-MAG migracja serwera z upgrade'em SQL Servera

Opisana procedura aktualizacji jest ok - przy założeniu oczywiście, że serwer jest "techniczny" i odpowiada powiedzmy za samą logikę bazy danych i nie odbywa się na nim praca np. terminalowa.
Jeśli tak to nie mam co do tego modelu uwag - proszę tylko mieć na uwadze to co pisałem w kwestii modułów wspólnych czyli podfolder w common files.

Jeśli chodzi o wymuszenie ponownej aktualizacji go proszę pamiętać, że ten przycisk robi tylko upgrade do wersji X. Znowu rozszerzając wątek poruszany przez Pana i moje drążenie tematu w kwestiach domyślności wersji zaznaczam, że w bardzo dużej mierze kod jest dostarczany przyrostowo co oznacza, że jeśli dany trigger od kilku wersji się nie zmienił to w tej wersji on nie będzie w ogóle dotknięty co może objawić się brakiem jakiejkolwiek zmiany.

W praktyce oznacza, to że ten trigger był poprawiony we wcześniejszych wersjach i teraz już nie jest aktualizowany do kolejnej zmiany w jego logice.

Zaproponowana i konsultowana z nami metoda przez serwis jest jedyną słuszną czyli dostarczenie triggerów w nowej wersji.
Jeśli dysponuje Pan narzędziem do dekompilacji hurtowej obiektów w bazie można łatwo wyciągnąć informację z obiektów systemowych w których triggerach znajduje się stara składania raiserror i przesłać wtedy taką listę do serwisu aby wszystkie obiekty zostały dostarczone.
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy


Następna dyskusja:

migracja z SQL2008 na SQL 2...




Wyślij zaproszenie do
Anuluj