Witam
Dzisiaj robiłem konwersje bazy danych z wersji 9.6 do wersji 9.8 podczas konwersji wystąpił błąd ze kilku Kontrahentów ma ten sam nip konwersja skończyła się błędem. Niestety nie posiadam kopi bezpieczeństwa nie zrobionej przez pomyłkę. Proszę o sugestie co mogę zrobić z taka baza danych czy można to jakoś cofnąć , nie idzie jej dokończyć wyskakuje informacja niewłaściwa wersja ?? Lub naprawić PILNIE POTRZEBUJE POMOCY
Konwersja Bazy Bład
Moderator: mikey
-
Przemek
- Posty: 292
- Rejestracja: 22 kwie 2008, 20:08
- Rola: Konsultant CDN XL
- Lokalizacja: Kraków
- Kontakt:
Re: Konwersja Bazy Bład
Zmień w bazie nip tym kontrahentom ... i zrób kopie 
--
Pozdrawiam
Przemysław Lepiarz
CEO, Partner - Futuriti
https://futuriti.pl
https://blog.futuriti.pl
Chcesz wdrażać, serwisować i rozwijać Comarch ERP? Nasze rekrutacje: https://futuriti.pl/kariera
Pozdrawiam
Przemysław Lepiarz
CEO, Partner - Futuriti
https://futuriti.pl
https://blog.futuriti.pl
Chcesz wdrażać, serwisować i rozwijać Comarch ERP? Nasze rekrutacje: https://futuriti.pl/kariera
- S0Cool
- Posty: 150
- Rejestracja: 13 lut 2008, 10:49
- Rola: Administrator CDN XL
- Wersja: 2018
- Lokalizacja: śląskie
Re: Konwersja Bazy Bład
Po ptokach. Poprawa NIPów nic nie pomoże. Baza jest w wersji "ani takiej ani takiej". Nie da się z niej korzystać ani wersją 9.6, ani 9.8.
Oczywiście po poprawie NIPów wpis z numerem wersji można zmienić w tabeli CDN.SystemCDN, ale musiałbyś znać algorytm wyliczający umieszczoną tam zapobiegliwie sumę kontrolną.
Wyjścia masz dwa:
1. Odtwarzasz bazę z ostatniego istniejącego backupu i grzecznie prosisz użytkowników o uzupełnienie danych wprowadzonych pomiędzy tym backupem a fatalną próbą konwersji, po czym konwersję robisz jeszcze raz (nie zapominając tym razem o backupie i oczywiście o poprawie NIPów). To czy ta opcja jest realna zależy oczywiście od tego, kiedy robiłeś ostatni backup i ile danych trzeba wprowadzić powtórnie.
Zalety: radzisz sobie w ramach firmy i bez dodatkowych kosztów
Wady: dozgonna niewdzięczność użytkowników i nienajlepsza opinia o Tobie jako adminie. Chyba że przekonasz wszystkich że to była "awaria"
2. Zwracasz się do swojego partnera Comarch, który powinien być w stanie naprawić bazę (uaktualnić numer wersji w tabeli SystemCDN i wyliczyć sumę kontrolną)
Zalety: bez wielkiego uszczerbku na opinii
Wady: to kosztuje
O, przepraszam, trzecie wyjście:
3. Tak mi teraz przyszło do głowy:
- odtwarzasz bazę z ostatniego backupu obok bazy głównej (sprawdź trzy razy czy nie nadpiszesz sobie danych), może być nawet sprzed miesiąca, byle w wersji 9.6
- poprawiasz w tej testowej bazie NIPy kontrahentów
- rejestrujesz tę bazę w Managerze Baz
- zapuszczasz na niej konwersję do 9.8 (backupu nie musisz robić bo go masz
)
- jeśli konwersja przejdzie bez błędów, przepisujesz tabelę SystemCDN z bazy testowej na główną
No i sprawdzasz czy działa. Jeśli tak - jesteś wielki, łał! Jeśli nie, masz wciąż pozostałe dwa wyjścia.
Zalety: bez kosztów, opinia o adminie, który samodzielnie poradził sobie z poważną awarią systemu informatycznego szybuje pod niebiosa
Wady: trochę osobistej walki z narzędziami MSSQL
Jeśli trzecia opcja się powiedzie, wisisz mi piwo
Powodzenia!
Oczywiście po poprawie NIPów wpis z numerem wersji można zmienić w tabeli CDN.SystemCDN, ale musiałbyś znać algorytm wyliczający umieszczoną tam zapobiegliwie sumę kontrolną.
Wyjścia masz dwa:
1. Odtwarzasz bazę z ostatniego istniejącego backupu i grzecznie prosisz użytkowników o uzupełnienie danych wprowadzonych pomiędzy tym backupem a fatalną próbą konwersji, po czym konwersję robisz jeszcze raz (nie zapominając tym razem o backupie i oczywiście o poprawie NIPów). To czy ta opcja jest realna zależy oczywiście od tego, kiedy robiłeś ostatni backup i ile danych trzeba wprowadzić powtórnie.
Zalety: radzisz sobie w ramach firmy i bez dodatkowych kosztów
Wady: dozgonna niewdzięczność użytkowników i nienajlepsza opinia o Tobie jako adminie. Chyba że przekonasz wszystkich że to była "awaria"
2. Zwracasz się do swojego partnera Comarch, który powinien być w stanie naprawić bazę (uaktualnić numer wersji w tabeli SystemCDN i wyliczyć sumę kontrolną)
Zalety: bez wielkiego uszczerbku na opinii
Wady: to kosztuje
O, przepraszam, trzecie wyjście:
3. Tak mi teraz przyszło do głowy:
- odtwarzasz bazę z ostatniego backupu obok bazy głównej (sprawdź trzy razy czy nie nadpiszesz sobie danych), może być nawet sprzed miesiąca, byle w wersji 9.6
- poprawiasz w tej testowej bazie NIPy kontrahentów
- rejestrujesz tę bazę w Managerze Baz
- zapuszczasz na niej konwersję do 9.8 (backupu nie musisz robić bo go masz
- jeśli konwersja przejdzie bez błędów, przepisujesz tabelę SystemCDN z bazy testowej na główną
No i sprawdzasz czy działa. Jeśli tak - jesteś wielki, łał! Jeśli nie, masz wciąż pozostałe dwa wyjścia.
Zalety: bez kosztów, opinia o adminie, który samodzielnie poradził sobie z poważną awarią systemu informatycznego szybuje pod niebiosa
Wady: trochę osobistej walki z narzędziami MSSQL
Jeśli trzecia opcja się powiedzie, wisisz mi piwo
Powodzenia!
Niniejszy podpis był testowany na zwierzętach.
Nie rozumiały go.
Nie rozumiały go.
Re: Konwersja Bazy Bład
Jesteś Hardcorem 
Jeśli chodzi o komunikaty o duplikacji numerów NIP to pewnie przez własne triggery na tabeli KntKarty, wyłącz je prze konwersją.
Jeśli powiedzie CI się trzecia opcja podana przez S0Cool to stawiam piwo tobie i jemu
Powodzenia
Jeśli chodzi o komunikaty o duplikacji numerów NIP to pewnie przez własne triggery na tabeli KntKarty, wyłącz je prze konwersją.
Jeśli powiedzie CI się trzecia opcja podana przez S0Cool to stawiam piwo tobie i jemu
Powodzenia