Elektroda.pl
Elektroda.pl
X

Search our partners

Find the latest content on electronic components. Datasheets.com
Elektroda.pl
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

MS SQL 2012 - błąd przepełnienia arytmetycznego

Bródka 11 Jan 2022 19:04 516 19
  • #1
    Bródka

    Level 41  
    Cześć,

    Mam problem z bazą danych MS SQL 2012 - błąd wyświetla sie w programie Symfonia Finanse i Księgowość 2021.1.
    Z tego co wyczytałem w Internecie dotyczy on błędnej identyfikacji danych tinyint, smallint or int

    Tylko jak rozwiązać ten problem, jak znaleźć blednę dane bezpośrednio w bazie i je zmienić ?


    MS SQL 2012 - błąd przepełnienia arytmetycznego
  • #2
    PRL
    Level 39  
    Błąd nie zależy od bazy, a od deklaracji zmiennej w Symfonii lub pola w bazie.
    Przeczytaj ostatnie zdanie z komunikatu i tak zrób.
  • #3
    Bródka

    Level 41  
    PRL wrote:
    Błąd nie zależy od bazy, a od deklaracji zmiennej w Symfonii lub pola w bazie.

    Na środowisku wirtualnym postawiłem windows server 2012, symfonie, serwer sql (wersja 2016, pierwotnie była wersja 2012 która właśnie ma problem z tymi zmiennymi i da się pracować na danym wyciągu bankowym, bo tak naprawdę błąd dotyczy jednego rozliczenia wyciągów bankowych w tzw buforze programu i braku możliwości przy przepełnieniu zmiennej zapisu czy usunięciu takiego wyciągu, a sam dokument wyciągu jest bardzo duży
    Finalnie pozostaje aktualizacja sql'a na nowszą wersje, konwersja bazy i powinno działać
    PRL wrote:
    Przeczytaj ostatnie zdanie z komunikatu i tak zrób.

    W tej firmie to tak nie działa, jeśli nie wykupisz pakietu obsługi technicznej (nie licząc licencji które kosztuje kilkadziesiąt tysięcy rocznie) firma Ci nie pomoże.
  • #4
    PRL
    Level 39  
    Ale kto ma Ci pomóc, jak nie producent oprogramowania???
  • #5
    Bródka

    Level 41  
    PRL wrote:
    Ale kto ma Ci pomóc, jak nie producent oprogramowania???

    No właśnie, tylko tak jak Ci pisałem, u nich to tak nie działa, nie zadzwonisz do nich ponieważ automat po identyfikacji po NIP'e odrzuci polaczenie (brak wykupionej pomocy technicznej), a napisać maila możesz, ale wskażą ci pomoc do instrukcji online i tyle gdzie tego typu problemy nie występują.
    Jest to jedyny podmiot który spotkałem aby się tak zachowywał w stosunku do klienta.
  • #6
    PRL
    Level 39  
    Insert robi tak samo, Microsoft robi tak samo itd.
    Jedno jest pewne - jest to błąd aplikacji. Jakiś wcześniej niezdiagnozowany. Pewnie jesteś pierwszym, masz pecha. Nic z tym chyba nie zrobisz od strony MSSQL. Wniosek jeden.

    P.S. Zmień tytuł (nie asymetryczny, a arytmetyczny).
  • #7
    Bródka

    Level 41  
    PRL wrote:
    Insert robi tak samo, Microsoft robi tak samo itd.

    Do insertu zadzwonisz to chociaż z tobą pogadają :) , do MS też, fakt jakość obsługi rożna ale wsparcie w necie o wiele lepsze np fora itp.
    PRL wrote:
    Nic z tym chyba nie zrobisz od strony MSSQL

    Jak bym wiedział gdzie to zmiana tej wartości to nie problem, ale bez wparcia producenta nie wiem gdzie znajduję się ta zmienna
  • #8
    PRL
    Level 39  
    Insert już wyłączył darmowe wsparcie telefoniczne. Microsoft też.
    Quote:
    nie wiem gdzie znajduję się ta zmienna

    W kodzie programu.;)
    Pokombinowałbym z 'tym przelewem'. Nie znam Symfonii. Ten przelew importujesz z pliku? Może któraś z danych ma większą wartość, niż określona w programie.
  • #9
    Bródka

    Level 41  
    PRL wrote:
    W kodzie programu.

    Nie no smallint, int, bigint to wartości tabeli w bazie sql, wystarczy ze jest tam smallint, a wartość przekracza np 3 miliony i wychodzą błędy. Rozwiązanie problemu w bazie powinno pomoc ale to już gdybanie bo nie wiemy czy to wina bazy która w tej wersji miała ten problem, czy programu który blednie zapisał dane do bazy i są kwiatki.
    PRL wrote:
    Pokombinowałbym z 'tym przelewem'. Nie znam Symfonii. Ten przelew importujesz z pliku? Może któraś z danych ma większą wartość, niż określona w programie.

    To inaczej wygląda dana firma ma iles tam kont bankowych, na podstawie plików dostarczanych przez bank wyciągi bankowe są odpowiednio importowane do programu - do bufora - później odpowiednio zbierane w konkretny dokument z przelewami, wypłat dla pracowników, potrącanych z wynagrodzeń kwot itd. po tym odpowiednio się go księguje
  • #10
    PRL
    Level 39  
    A co zapisuje w bazie dane, jak nie program???
    Jest przepełnienie i tyle.
  • #11
    Sam Sung
    Level 32  
    Próbowałeś się wpiąć w połączenie klienta z serwerem bazy i zobaczyć, jakie zapytania tam lecą?
    Może Wiresharkiem udałoby się to zobaczyć?
  • #12
    PRL
    Level 39  
    I jak postępy? Znalazłeś te 40065 w .csv?
  • #13
    Bródka

    Level 41  
    Sam Sung wrote:
    Próbowałeś się wpiąć w połączenie klienta z serwerem bazy i zobaczyć, jakie zapytania tam lecą?
    Może Wiresharkiem udałoby się to zobaczyć?

    Nie próbowałem, ale na produkcyjnej instancji robić tego nie będę, bo to tylko jednak z kilkudziesięciu baz ma ten problem
    PRL wrote:
    I jak postępy?

    Tak jak pisałem, na osobnym srodowisku działa po aktualizacji sql do nowsze wersji. Środowisko produkcyjne jest na wirtualizacji wiec przez weekend dam eksport wirtualki i uruchomię na innym sprzęcie tą wirtualke, jak tam pójdzie to już na produkcyjnym puści się
    PRL wrote:
    Znalazłeś te 40065 w .csv?

    W csv ?
    Tak naprawdę nie wiadomo czego dotyczy ten błąd w bazie, ale w sumie już nie ma sensu szukać bo jest rozwiązanie, aktualizacja sql i konwersja bazy do nowszej wersji rozwiązuje problem
  • #14
    PRL
    Level 39  
    Quote:
    W csv ?

    Myślałem, że wyciągi z banku dostajesz w .csv...
  • #15
    Bródka

    Level 41  
    PRL wrote:
    Myślałem, że wyciągi z banku dostajesz w .csv...

    Wyciągi są dostarczane w formacie MT940 - a sam problem nie dotyczy jednego wyciągu bo te się importują bez problemu, tylko tworząc dokument zbioru tych wyciągów juz w programie po przetworzeniu wyciągów dokument sie sypie
  • #16
    PRL
    Level 39  
    Teoretycznie, to instalacja nowszej wersji serwera nic nie powinna zmienić, jeśli chodzi o błąd z #1, bo 'krytyczne' pole nie zmieniło swojego typu ze smallint na większy. Wydaje się, że to jakiś zbieg okoliczności wystąpił.
  • #17
    Bródka

    Level 41  
    PRL wrote:
    Teoretycznie, to instalacja nowszej wersji serwera nic nie powinna zmienić

    Zmieni, bo tak jak pisałem SQL w wersji 2012 ma błąd
    https://docs.microsoft.com/en-us/sql/t-sql/da...nd-tinyint-transact-sql?view=sql-server-ver15
    PRL wrote:
    Wydaje się, że to jakiś zbieg okoliczności wystąpił.

    No proszę Cię, tu nie ma zbiegu okoliczności, pracuje na dwóch identycznych bazach, różnica jest w wersji SQL'a
  • #18
    PRL
    Level 39  
    Ten link nic nie mówi o błędzie.:)
    Quote:
    różnica jest w wersji SQL'a

    Rozumiem, jednak zmiana silnika nie zmieniła przecież typu pola w tabeli.
    Jak dla mnie, to błąd z #1 powodował INSERT wartości 40065 do pola smallint.
    Quote:
    tak jak pisałem SQL w wersji 2012 ma błąd

    To zgłoś do MS, a coś zarobisz.
  • #19
    Bródka

    Level 41  
    PRL wrote:
    Jak dla mnie, to błąd z #1 powodował INSERT wartości 40065 do pola smallint.

    Tak i kopia w kopie taka sama baza robi na jednym silniku błąd, na drugim nie ?
    Nazywasz to przypadkiem ?
    Gdzieś jest błąd, nie mnie to sprawdzać co jest/było przyczyną błędu, ważne że obecnie działa
    PRL wrote:
    Ten link nic nie mówi o błędzie

    https://www.youtube.com/results?search_query=sql+2012+arytmetic+error
    PRL wrote:
    Rozumiem, jednak zmiana silnika nie zmieniła przecież typu pola w tabeli.

    Ale zmieniła jego interpretacje po stronie silnika, SQL widzi błąd ale nie wariuje tylko zmienia np na bigint, a nie wywala błędy, przykłady w w filmach na YU powyżej
    PRL wrote:
    To zgłoś do MS, a coś zarobisz.

    Zostawiam Ci wolną rękę ;)
  • #20
    adamas_nt
    Moderator of Programming
    Bródka wrote:
    aktualizacja sql i konwersja bazy do nowszej wersji rozwiązuje problem
    W związku z tym nie widzę sensu dalszej dyskusji. Temat zamykam.