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...

Czyli sugerujcie Panowie reindeksacje wszystkich tabel i ich indeksow czy tylko konkretnych? Jestem przekonany, że jakiś czas temu już to próbowałem robić. Czy są jakieś narzędzia dostarczone do subiekta którymi można byłby sprawdzić konsystencje samych danych?

Witam, Z samą bazą danych jest w porzadku, narzedzia mssql nie pokazując żadnych problemów. Chodzi tu raczej o integralność danych na poziomie subiekta a nie bazy. Czy została reindeksacja? - nie. Pytanie czy to reindeksacja na bazie nie rozwali Insertowskiego "Instynktu"?

Witam, Wersja Nexo : 34.1.0(4320) Silnik Bazy danych: Microsoft SQL Server 2019 (RTM-GDR) (KB4583458) - 15.0.2080.9 (X64) Nov 6 2020 16:50:01 Copyright (C) 2019 Microsoft Corporation Standard Edition (64-bit) on Windows 10 Pro 10.0 <X64> (Build 19041: ) (Hypervisor) Baza podmiot: Ilość danych: Zużycie zasobów na serwerze: Ram: 32Gb Procesor: i7-4790 Dysk: SSD Pod bazę podpiętych jest kilka rozwiązań sferycznych. Od jakiegoś czasu wydajność subiekta diametralnie spadła. Sam interfejs Subiekta Nexo ciągle wywala się błędami typu: Błędy z poziomu sfery: InsERT.Mox.DataAccess.DataAccessException: Wystąpił błąd dostępu do danych. ---> System.Data.Entity.Core.UpdateException: An error occurred while updating the entries. See the inner exception for details. ---> System.Data.SqlClient.SqlException: Upłynął limit czasu wykonywania. Limit upłynął przed ukończeniem operacji lub serwer nie odpowiada. ---> System.ComponentModel.Win32Exception: Upłynął limit czasu operacji oczekiwania --- Koniec śladu stosu wyjątków wewnętrznych --- w System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction) w System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction) w System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose) w System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Boolean& dataReady) w System.Data.SqlClient.SqlDataReader.TryConsumeMetaData() w System.Data.SqlClient.SqlDataReader.get_MetaData() w System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString, Boolean isInternal, Boolean forDescribeParameterEncryption, Boolean shouldCacheForAlwaysEncrypted) w System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async, Int32 timeout, Task& task, Boolean asyncWrite, Boolean inRetry, SqlDataReader ds, Boolean describeParameterEncryptionRequest) w System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, TaskCompletionSource`1 completion, Int32 timeout, Task& task, Boolean& usedCache, Boolean asyncWrite, Boolean inRetry) w System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method) w System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior, String method) w System.Data.SqlClient.SqlCommand.ExecuteDbDataReader(CommandBehavior behavior) w System.Data.Common.DbCommand.ExecuteReader(CommandBehavior behavior) w System.Data.Entity.Core.Mapping.Update.Internal.DynamicUpdateCommand.Execute(Dictionary`2 identifierValues, List`1 generatedValues, IDbCommandInterceptor commandInterceptor) w System.Data.Entity.Core.Mapping.Update.Internal.UpdateTranslator.Update() --- Koniec śladu stosu wyjątków wewnętrznych --- w System.Data.Entity.Core.Mapping.Update.Internal.UpdateTranslator.Update() w System.Data.Entity.Core.EntityClient.Internal.EntityAdapter.<>c.<Update>b__18_0(UpdateTranslator ut) w System.Data.Entity.Core.EntityClient.Internal.EntityAdapter.Update[T](IEntityStateManager entityCache, T noChangesResult, Func`2 updateFunction, Boolean throwOnClosedConnection) w System.Data.Entity.Core.EntityClient.Internal.EntityAdapter.Update(IEntityStateManager entityCache, Boolean throwOnClosedConnection) w System.Data.Entity.Core.Objects.ObjectContext.<SaveChangesToStore>b__125_0() w System.Data.Entity.Core.Objects.ObjectContext.ExecuteInTransaction[T](Func`1 func) w System.Data.Entity.Core.Objects.ObjectContext.SaveChangesToStore(SaveOptions options) w System.Data.Entity.Core.Objects.ObjectContext.SaveChanges(SaveOptions options) w InsERT.Mox.DataAccess.EntityFramework.UnitOfWorkAwareObjectContext.HandleChangesSaveRequest(Object sender, ChangesSaveRequestEventArgs args) --- Koniec śladu stosu wyjątków wewnętrznych --- w InsERT.Mox.DataAccess.EntityFramework.UnitOfWorkAwareObjectContext.HandleChangesSaveRequest(Object sender, ChangesSaveRequestEventArgs args) w InsERT.Mox.Work.UnitOfWork.SaveChanges2(Boolean saveRequestVetoed, Boolean changesWereSaved) w InsERT.Mox.Work.UnitOfWork.SaveChanges() w InsERT.Mox.BusinessObjects.BusinessObject`3.Zapisz() Ilość danych jest śmiesznie niska, moim zadaniem aplikacja nie powinna w ogóle mieć problemów wydajnościowych. Rozwiązania sferyczne są na tej samej maszynie co baza. Problemy sieciowe można pominąć. Gdzie mógłbym szukać rozwiązania tego problemu. Czy mają Państwo jakieś narzędzia diagnostyczne do badania konsystencji bazy danych? Na chwilę obecną korzystanie z subiekta staje się coraz większym wyzwaniem. Z góry dziękuję ze reakcję.