Tomasz Lapke

Witam, Chciałbym ponowić temat. Na serwerze produkcyjnym zdarzył nam się podobny przypadek. Z dnia na dzień aplikacje przestały komunikowac się ze sferą. DanePolaczenia dp = DanePolaczenia.Jawne(...) zaczął zwracać NULL. Odpowiadając na pytanie. OS i DB :Microsoft SQL Server 2019 (RTM-GDR) (KB5021125) - 15.0.2101.7 (X64) Jan 23 2023 13:08:05 Copyright (C) 2019 Microsoft Corporation Standard Edition (64-bit) on Windows 10 Pro 10.0 <X64> (Build 19045: ) (Hypervisor) Serwer z bazą jest na tej samej maszynie na której są aplikacje. Po przerzuceniu aplikacji na inną maszynę nie ma problemu. Co może powodować takie zachowanie?

Witam, rozumiem, że potencjalne naprawnienie problemu będzie skutkowało wypuszczenie jakiejś łatki? Czy do tego czasu są Państwo zasugerować jakieś pośrednie rozwiązanie problemu, żeby umożliwić normalną pracę w aplikacji? Z góry dziękuję za odpowiedź

Witam, Po wykonaniu operacji usunięcia witryny nic się nie stało. Nie wyświetla się, żaden komunikat o tym czy się powiodło czy nie. Nie ma też żadnego komunikatu błędu. Operacje powtarzałem kilkukrotnie, bez żadnego rezultatu. Triggery które zostały ręcznie wyłączone nie zostały usunięte. W logach z prób widzę coś takiego Dodatkowo w logu głównym widzę wiele wpisów:

Witam Pani Anno, Zgadza się sama witryna nie została usunięta. Rozumiem, że wystarczy z poziomu samego subiekta użyć przyciusku "Usuń witryunę" i to powinno wywalić wszystkie obiekty bazodanowe związane z vendero z bazy subiekta? Chciałbym zaznaczyć, że "Status procesu synchronizacji" jest wyłączony mimo to, triggery na bazie cały czas działały i zbierały dane do tabeli Vendero_Synch. Nawet gdybyśmy mieli cały czas vendero dostępne czy to normalne, że rozwiązanie samo ze sobą wchodzi w konflikty i generuje deadlocki?

Witam, Nie na innych listach nie dochodzi do zacinania aplikacji. W każdej możliwej kombinacji. Występuje również na kliencie zainstalowanym na serwerze - zerowa komunikacja sieciowa poza loopback

Witam, Klient Subiekta nexo notorycznie zawiesza się przy wejściu w widok rozrachunków. Aplikacja ładuje dane "pokazuje się animowany progress bar indicator" po czym aplikacja wchodzi w "Brak odpowiedzi" a następnie w zależności od widzimisię odpuszcza po kilkudziesięciu sekundach do kilku minut... Często w ogóle nie odpuszcza, program zawieszony jest permanentnie, trzeba go ubić i załadować ponownie. W logach klienta pusto, zero informacji o błędach. Czy mają Państwo jakieś sugestie jak można byłoby to poprawić?

Rozumiem, postaram się właśnie w taki sposób to ustalać. Mam pytanie pomocnicze jeszcze. Czy istnieje możliwość sprawdzenia który kod sferyczny jest wywoływany przez GUI subiekta? Czy mają Państwo może kiedyś w planach nagrywanie makr? Czy na chwilę obecną zostaje reverse engineering i używanie narzędzi typu ILSpy?

Zgadza się. Podmiot był definiowany po wymuszeniu liczenia po brutto... Dokładnie tak sam problem był z ustawieniem pola "Realizuj jako". if (sourceMember.IsInvoice > 0) { destination.KonfiguracjaRealizujacego = uchwyt.PodajObiektTypu<IKonfiguracje>().DaneDomyslne.FakturaVAT; } else { destination.KonfiguracjaRealizujacego = uchwyt.PodajObiektTypu<IKonfiguracje>().DaneDomyslne.ParagonImienny; } Po przeniesieniu tej sekcji po zdefiniowaniu kontrahenta problem ustąpił. Dziękuję za pomoc. Czy jest gdzieś w API opisane, jaka powinna być sekwencja ustalania wartości dla pól w dokumencie, aby mieć pewność, że API pod spodem samo sobie tego nie pozmienia? Albo chociaż relacje, jakie pola mają wpływ na jakie właściwości dokumentu?

Dokumentu sferycznie jest również liczony od brutto: destination.OperacjePrzeliczaniaPozycji = OperacjePrzeliczaniaPozycji.Brutto_ID; Poniżej sposób uzupełnienia pozycji: public void Convert(ItemDto sourceMember, PozycjaDokumentu destination) { //logger.Debug("Convert: " + sourceMember + ", destination: " + destination); if (sourceMember == null) { throw new ArgumentNullException(nameof(sourceMember)); } if (destination == null) { throw new ArgumentNullException(nameof(destination)); } var uchwyt = launcher.Connect(); destination.Ilosc = sourceMember.Quantity; destination.StawkaVat = uchwyt.Dane<StawkaVat>().SingleOrDefault(x => x.Stawka == sourceMember.TaxRate); destination.Cena.RodzajRabatu = (int)InsERT.Moria.Dokumenty.Logistyka.RodzajRabatu.ProcentowyOdWartosci; destination.Cena.BruttoPrzedRabatem = sourceMember.GrossPrice; destination.Cena.RabatProcent = sourceMember.DiscountPercent; logger.Debug($"NettoPrzedRabatem: {destination.Cena.NettoPrzedRabatem}, BruttoPrzedRabatem: { destination.Cena.BruttoPrzedRabatem}, RabatProcent: {destination.Cena.RabatProcent}, NettoPoRabacie: { destination.Cena.NettoPoRabacie}, BruttoPoRabacie: { destination.Cena.BruttoPoRabacie}, WartośćBruttoPoRabacie: {destination.Wartosc.BruttoPoRabacie}"); }

Witam, Mam rozwiązanie które ściąga zamówienia z zewnętrznego systemu, a następnie wrzuca je do subiekta. Raz na jakiś czas zdarzają się błędy gdzie wyliczane podsumowanie z poziomu subiekta różni się od wyliczeń, z zewnętrznego rozwiązania. Wziąłem jeden z takich przypadków do analizy i wyszła dziwna rzecz. Po wprowadzeniu danych ręcznie do subiekta wychodzą takie same wartości jak z zewnętrznego systemu. Natomiast po wprowadzeniu tych samych danych przez sferę wychodzą różnice, prawdopodobnie w zaokrągleniach. Klient subiekta "pod spodem" używa tych samych rozwiązań sferycznych. Dlaczego w takim razie klient liczy inaczej niż sfera? W każdej pozycji został użyty rodzaj rabatu procent od wartości (20%). Dokument jest liczony od brutto.

Problem jaki mieliśmy był związany z ciągłym zawieszaniem edycji dokumentów. Mamy rozwiązania sferyczne które ciągle ładują zamówienia z systemów zewnętrznych, generują paragony fiskalizują... W sumie generowanych sferycznie kilka/kilkanaście tysięcy dokumentów dziennie. Klienty subiekta zainstalowane na końcówkach podczas edycji dokumentów, ciągle się zacinały "Brak odpowiedzi", wywalały błędy z "przekroczeniem czasu oczekiwania na operacje", deadlockami. Niemożliwość normalnej pracy. Analiza tego to koszmar, którego nikomu nie życzę, OS, hardware, sieć, baza - wszystko przetrzepane. Problem rozwiązany. Wystarczyło wyłączyć wszystkie triggery z prefixem Vendero_* i wszystkie problemy ustąpiły. Myślę, że dobrze by było gdyby ktoś z INSERTU zainteresował się tym babolem i go poprawił. Ciekaw jestem ile jeszcze taki kwiatków siedzi na bazie i kiedy wybiją....

Witam, podmiot korzystał przez jakiś czas z Vendero. Ostatecznie zrezygnował z niego. Vendero zostało wyłączone. Niestety mimo iż nie jest używane w ciągu dalszym powoduje problemy na bazie. W jaki sposób można to ostatecznie wyczyścić i wyłączyć?

Dobrze wiedzieć następny razem spróbuję tego rozwiązania. Zobaczymy czy sprawdzi się ono równie dobrze. BTW Nie dało się podpowiedzieć tego od razu:)?

Witam, Rzeczywiście reindeksacja pomogła. Gdyby ktoś miał podobne problemy to poniżej sql do wykonania na bazie (wszystkie usługi i klienci powinni być odpięci od bazy przed puszczeniem, dodatkowo myślę, że backup nie zaszkodzi, sql zwraca output jeżeli coś się schrzani): declare @tableName nvarchar(255) declare myCursor CURSOR FOR select TABLE_SCHEMA+'.'+TABLE_NAME from INFORMATION_SCHEMA.TABLES where TABLE_TYPE = 'base table' open myCursor Fetch next from myCursor into @tableName While @@FETCH_STATUS = 0 Begin print 'Working on: '+@tableName DBCC DBREINDEX(@TableName,' ',90) Fetch next from myCursor into @tableName end close myCursor Deallocate myCursor Myślę, że będę musiał zrobić jakieś joba który reindeksacje będzie wykonywać cyklicznie...

Witam, Rzeczywiście reindeksacja pomogła. Gdyby ktoś miał podobne problemy to poniżej sql do wykonania na bazie (wszystkie usługi i klienci powinni być odpięci od bazy przed puszczeniem, dodatkowo myślę, że backup nie zaszkodzi, sql zwraca output jeżeli coś się schrzani): declare @tableName nvarchar(255) declare myCursor CURSOR FOR select TABLE_SCHEMA+'.'+TABLE_NAME from INFORMATION_SCHEMA.TABLES where TABLE_TYPE = 'base table' open myCursor Fetch next from myCursor into @tableName While @@FETCH_STATUS = 0 Begin print 'Working on: '+@tableName DBCC DBREINDEX(@TableName,' ',90) Fetch next from myCursor into @tableName end close myCursor Deallocate myCursor Myślę, że będę musiał zrobić jakieś joba który reindeksacje będzie wykonywać cyklicznie...