Artur Mechliński

Dziękuję za odpowiedź. Henry Ford kiedyś powiedział, że gdyby przed rozpoczęciem produkcji samochodów zapytał ludzi czego chcą do szybszego przemieszczania się, to by mu odpowiedzieli, że szybszych koni. Ciekaw jestem co wyjdzie z tego zbierania informacji wśród użytkowników Subiekta (123?) zamiast wśród reprezentatywnej grupy potencjalnych klientów (np. przedsiębiorców na Allegro), ponieważ na e-commerce macie ich najwięcej w linii Subiekt GT. Nie w 123 ani nie w nexo. Nowi klienci z kolei idą do konkurencji a klienci Biur Rachunkowych, pracujących na insERT są zmuszeni do korzystania z np. wFirmy, iFirmy itp. które dodatkowo stanowią konkurencję dla Biur oraz dla Was. Dodam, że konkurencja oferuje takie rozwiązania zarówno dla klientów jak i dla księgowych (biur) tych klientów. Standard poszedł w górę.

Podbijam temat. Nasi Klienci korzystają z konkurencyjnych rozwiązań, ponieważ nie wiedzą/wiemy czy istnieje oraz jak działa integracja z Allegro. Mamy wykupioną licencję Subiekt 123 dla klientów biur rachunkowych, więc chcielibyśmy aby korzystali z rozwiązania, za które dla nich płacimy.

Dziękuję za konkretne rozwiązanie. Po ręcznej zmianie rekordu problem komunikatu zniknął. Jednak, gdy mogłem już zweryfikować tę kłopotliwą bazę jak i zajrzeć w pozostałe bazy danych klientów wg powyższych wytycznych, to mogę wskazać, co generuje taki błąd. Nie jest nim z pewnością przerwanie działania kreatora. W naszym przypadku będzie to sytuacja uruchomienia kreatora, gdy podmiot już istniał od lat np. przejście z KPiR na KH (Rewizor uruchamia wtedy kreator). Użytkownik Windows w takim przypadku zapisany w bazie to użytkownik z roku założenia podmiotu i dodatkowo przypisany do stanowiska/domeny jaka wtedy obowiązywała. U nas był to rok 2017, czyli 6 lat temu. Od tego czasu zmieniła się infrastruktura IT, konta użytkowników oraz komputery w domenie. Jeżeli w zespole mamy więcej osób, które mogą zakładać nowe podmioty, to po latach jest niemal niemożliwe aby 'strzelić' w to konto użytkownika, które zostało przypisane do bazy, o ile w ogóle jest taka możliwość (mógł to być np. admin lokalny na stanowisku o numerze/nazwie wycofanej z użycia). W każdym razie powyższe rozwiązanie usuwa problem ale wymaga wiedzy z zakresu ingerencji w bazę danych. Pozdrawiam.

Rozumiem, że muszę założyć oddzielny wątek, gdyż tak wspaniałe rozwiązanie jak usuwanie podmiotu z bazy danych i założenie go na nowo uznano za "rozwiązanie" na tyle doskonałe, że nie ma co dopytywać dalej w tym wątku o inne opcje. Rozwiązanie na miarę "informatyka", którego głównym orężem na problemy jest format dysku i przywracanie systemu.

Dzień dobry. Ciekawa odpowiedź Mam ten sam problem, lecz usuwanie podmiotu nie wchodzi w grę, gdyż dotyczy klienta, który przeszedł z KPIR na KH. Tym samym podmiot z Rachmistrza jest tworzony w Rewizorze i kreator utknął dokładnie w tym miejscu jak u Pani Iwony. Proszę o inne sugestie niż usuwanie. Poza tym miło by było wiedzieć o co w ogóle chodzi z tym komunikatem i dlaczego się pojawia?

Aplikacja webowa może dłużej się otwierać pierwszy raz po aktualizacji i po wejściu w opcje, które nie były jeszcze otwierane. Przy kolejnym otwarciu powinno działać szybciej. U mnie działa (Safari, Chrome)

Trzeba wstać od komputera i zrobić 3 obroty a później zastukać obcasami. Koniecznie w tej kolejności. Następnie można już się logować do nowej wersji

Jak widać temat nie zainteresował nikogo z Insertu od marca. Natomiast zainteresował mnie. Które konkurencyjne rozwiązania Panie Michale oferują tak rozbudowany portal dla klientów? Czy ma Pan na myśli księgowość online prowadzoną przez różne firmy internetowe i banki czy konkurencyjny do Insertu nexo program adresowany do biur rachunkowych?

Dziękuję za szczegółowy opis problemu oraz deklarację usprawnień. Spróbuję wykonać zasugerowane rozwiązania i mam nadzieję, że uda mi się wygospodarować przestrzeń umożliwiającą wydajną pracę z programem Biuro. Być może nastąpiło nieporozumienie, gdyż faktycznie nie rozumiem dlaczego program wykonuje konwersję baza po bazie a pomimo tej sekwencyjnej czynności na koniec każdej konwersji nie kompresuje tego archiwum lub po prostu go nie usuwa. W kwestii owych 15GB sprawa wyglądała tak, że podczas kolejnej próby konwersji zbiorowej (po wcześniejszym posiadaniu wolnych około 50GB) zabrakło nam miejsca na serwerze i nie zostało praktycznie nic. Konwersja została przerwana mniej więcej w połowie. Następnego dnia wyszła kolejna aktualizacja, więc chciałem ponowić procedurę aby dokończyć proces i licząc, że nowsza wersja ma jakieś usprawnienia w tej kwestii. Udało mi się w tym celu zwolnić 15GB (wcześniej sprawdzając ile zajmuje archiwum wszyskich baz (skompresowane). Odpaliłem konwersję zbiorową i po pewnym czasie ponownie pozostałem bez miejsca na dysku a aktualizacja podmiotów została przerwana na mniej więcej 25% firm. Obecnie mam więc spory bałagan jeżeli chodzi o wersje programów, gdyż podmioty z początku listy mają najnowsze wersje a na końcu nigdy nie były aktualizowane. Czekam zatem z niecierpliwością na aktualizację rozwiązującą ten problem.

Nasze biuro dopiero zaczęło korzystać z nexo, więc na dobrą sprawę baza jest niemal pusta w porównaniu ze starym oprogramowaniem innej firmy, której archiwa z 10 lat (Kpir, ksh, kadry i płace) mieszczą się w 1GB archiwum a programy (na każdy rok oddzielny) zajmują 7,3GB. Nasz katalog deployments miał 105GB (wersja 13 oryginalnie instalowana oraz 1 raz aktualizowano podmioty). Po konsultacji z informatykiem usunąłem deployments, robiąc jego kopię na zewnętrznym dysku ale ku mojemu zdziwieniu powierzchnia dysku została bez zmian. W koszu nic się nie pojawiło, nowych plików nie zauważyłem, stare niby zniknęły, 100GB także nie ma. Czarna magia. Widzę jak pliki znikają. Widzę, że deployments jest pusty a ponad 100GB nadal gdzieś jest i nie wiadomo gdzie. Przynajmniej do czasu jak informatyk nie rozpocznie dochodzenia to ja tego nie wiem. Skoro kilka wersji programu jak u Pana Radomiła dla 3 podmiotów potrafi zająć 24GB, to nie wyobrażam sobie co się będzie działo u nas później oraz jakim cudem ma nam starczyć 300GB na serwerze. Koszmar. Zwłaszcza, że używamy niemal pełnego pakietu programów nexo. Wymiana dysków w systemie RAID na serwerze to nie jest taka niewinna zabawa jak na zwykłym komputerze, więc mam nadzieję, że nie będę zmuszony do zlecenia tej "operacji na otwartym sercu"

Podczas konwersji baz program wymaga gigantycznych ilości przestrzeni na dysku serwera. Zanim zainstalowaliśmy pakiet nexo, na naszym serwerze wolne było ponad 120GB a obecnie został nam 1GB. Połowa klientów nadal nie ma najnowszej wersji, gdyż zbiorowo jest to już niewykonalne a ręczne aktualizowanie znacznej ilości klientów będzie pracą bez końca, gdyż zanim skończę wyjdzie kolejna aktualizacja Program "puchnie" w niebywałym tempie, gdyż ten decyduje za mnie o archiwizacji danych przed konwersją i nie daje mi opcji wyboru aby nie zrobić archiwum lub zrobić tymczasowe, które następnie sam usunie. Co ciekawe, jeżeli ten proces (konwersji) zostanie przerwany z powodu braku miejsca, przestrzeń nie zostanie oczyszczona lecz znika w zastraszajacym tempie. Jeżeli używam mechanizmu archiwizacji (przed konwersją) silnika bazy SQL, to sprawia, że do dziś szukam gdzie się podziało 100GB. Próba usunięcia plików "deployments" wywołuje jeszcze dziwniejsze zjawisko. Na moich oczach bowiem pliki są usuwane (opcja usuń PERMANENTNIE) ale przestrzeń się nie zwalnia. Kolejna zagadka to fakt, że archiwum wykonane w programie serwisowym wszystkich firm zajmuje 7,5GB a próba konwersji zaledwie 25% firm zakończona zostaje z powodu braku miejsca po "zjedzeniu" aż... 15GB. Czy potraficie mi wyjaśnić i doradzić jak spuścić powietrze z tego nadmuchanego balona?