Skocz do zawartości

Nieudana aktualizacja do wersji 1.6301.1.4818 z wersji 1.6206.22.4746

Polecane posty

Muszę zgromadzić cała masę danych aby wysłać Insertowi zapytanie o jego ewentualną pomoc. Nie wystarczy mój login uwiarygodniony wcześniej licencją.

To jest dwór - wpuszczają tylko szlachtę.

Pamiętam Inserta z lat 2006-2008 gdy wyciągał do użytkownika pomocną dłoń i odbierał telefony przez cały dzień. Dziś wyciąga tylko kieszeń.

 

 

Link to postu

Aby nie być gołosłownym - w 2006/2007 dostałem z Inserta wsparcie w postaci opisu bazy danych. Rozmówca nie tylko udzielił mi informacji n/t jej struktury ale pomógł w rozwiązaniu problemu. I to nie kierując mnie do TeleKonsultanta.

W załączniku ówczesne pliki - może społeczność skorzysta.

Dokumentacja_DB.xml Dokumentacja_DB.xsl

Link to postu

Czy mogłem więc wtedy przypuszczać, że Firma zmieni swoje nastawienie do klientów? No skądże! Byli tacy słodcy.

Dzisiaj jednakże muszę stracić kilkanaście minut aby w ogóle wysłać im powiadomienie o znalezieniu przesłanki do wzbudzenia poważnej wątpliwości  co do ich jakości jako przedsiębiorcy.

I to takiej twardej przesłanki - bazującej na historii rozwoju MS SQL Server, będącego fundamentem rozwoju firmy uznanej jako Microsft  Certified for Windows 2000.

W lutym 2001 roku program Analityk firmy InsERT S.A. został wyróżniony tytułem Certified for Windows 2000 Professional . Tytuł ten oznacza, że aplikacja spełnia rygorystyczne wymagania techniczne; potwierdza przede wszystkim dużą niezawodność, łatwość obsługi i niższe koszty zarządzania. InsERT S.A. jest pierwszą w Polsce firmą, której produkt uzyskał tytuł Certified for Windows 2000 Professional dla aplikacji typu Desktop. 

To pierwsze z brzegu uściski Inserta z Microsoftem.

 

A tymczasem spotykam się z zarzutem - z otoczenia tejże firmy certyfikowanej przez Microsoft - że usunąłem w bazie danych rekord zawierający wielkość desygnowaną jako FOREIGN KEY, bądź taką, która powinna być desygnowana jako FOREIGN KEY.

Ja już się śmieję, ale wielu nieświadomych, płacących swoje myto użytkowników zaśmieje się za chwilę.

 

Edytowane przez Kamil Rad
zmiana "wartości" na "wielkość" - dla purystów i dla mnie"
Link to postu

Dzisiaj końcowe podsumowanie problemu i podanie jego najbardziej prawdopodobnej przyczyny.

Zakładam, że wraz z wprowadzeniem pod koniec 2010 roku "tymczasowej" stawki VAT w wysokości 23% wprowadziłem do stawek Vat ( tabela "sl_StawkaVat") niezbędną pozycję o wartości 23% i nazwałem ją powiedzmy "Tymczasowa stawka VAT 23%". W maju 2011 zdałem sobie sprawę, że tymczasowość będzie trwała ( vide podatek Belki) i usunąłem tę pozycję, wpisując na jej miejsce nową stawkę w wysokości także 23% i nazwie "Podstawowy podatek VAT 23%". Wygląda na to, że zmieniłem także te stawki w większości dokumentów - ale nie we wszystkich. Z punktu widzenia bazy danych ( tabela "sl_StawkaVat") wpis nowej stawki nie odbył się "w miejsce" starej tylko dodano kolejną stawkę, a starą usunięto. W ten sposób na niepoprawionych dokumentach - tych znalezionych kwerendą "StawkiVatSQL-infants-dokumenty-numery" - istniało odwołanie do nieistniejącego wiersza w tabeli "sl_StawkaVat".

Jak jednak mogło do tego dojść? Silnik bazy danych InsertaGT, czyli MS SQL Server, automatycznie nakłada na nowo tworzoną tabelę ( dzieje się to np. przy instalowaniu programu) klauzulę "ON DELETE" o wartości "NO ACTION". Oznacza to, że w przypadku usuwania wiersza z tabeli "sl_StawkaVat" SQL Server sprawdzi, czy jakaś inna tabela deklarująca odwoływanie się do jej wierszy ( np. "ob_Pozycja") nie odwołuje się do tego konkretnego wiersza i jeśli takie odwołanie będzie to nie pozwoli na usunięcie wiersza z tabeli "sl_StawkaVat".
Moja przygoda z InsertGT trwa od wersji 1.06, która była dystrybuowana wraz z MS SQL Server 2000 i taka funkcjonalność ( tzn. "ON DELETE NO ACTION") już w nim była.

Aby pozwolić MS SQL Server na usuwanie z tabeli "sl_VatId" wierszy używanych w innej tabeli należy:

1. Zmienić wartość klazuli "ON DELETE" z "NO ACTION" na np "SET NULL" i wtedy wartość pola "ob_VatId" w tabeli "ob_Pozycja" zostanie wyczyszczona
lub
2. Nie zadeklarować w tabeli "ob_Pozycja" pola "ob_VatId" jako "FOREIGN KEY" przez co server nie będzie sprawdzał w tabeli "ob_Pozycja" odwołań do usuwanego wiersza tabeli "sl_StawkaVat".

Oba te rozwiązania są jednak błędem programowym, bo prowadzą do utraty spójności danych w bazie skutkującym z kolei błędem walidacji matrycy VAT i w konsekwencji zamykają drogę do aktualizacji oprogramowania.

Rynek motoryzacyjny przyzwyczaił nas do bezpłatnych akcji serwisowych w sytuacji gdy producent pojazdu coś sknoci i chce to naprawić.
Czy zastąpienie takiego zachowania opcją płatnej usługi AutoKonsultanta lub odesłanie do płatnego serwisu zewnętrznego mogłoby się przyjąć na tamtym rynku?

Pozdrawiam wszystkich serdecznie i dziękuję za uwagę,
KR

Edytowane przez Kamil Rad
Link to postu
×
×
  • Dodaj nową pozycję...