Katarzyna Rozmarynowska

Przypuszczam, że ma Pan .NET Framework 4.8.1, na którym nie działają wersje nexo starsze niż 41.2.1. Są dwa wyjścia z tej sytuacji: zrobić tymczasowy downgrade .NET Framework, zainstalować wersję 37, potem bez odinstalowywania doinstalować wersję 50. Wtedy program powinien się uruchomić (bo launcher, czyli aplikacja do wyboru podmiotu, będzie już w wersji 50, nawet gdy podmiot jest jeszcze w wersji < 50). Podczas aktualizacji podmiotu do wyboru powinny być wersje 37 i 50. Należy zaktualizować podmiot najpierw do 37, a potem 50.

Szanowni Państwo, od wersji 51 (czerwiec 2024) przestaniemy dołączać do nexowego SDK rozszerzenie z szablonami projektów dla Visual Studio w wersji 2019. Rozszerzenie dla wersji 2022 zostaje oczywiście na swoim miejscu i serdecznie zachęcamy, by z niego korzystać.

Nexo nie usuwa procedur użytkownika przy aktualizacji, zwłaszcza jeśli są one w dbo czy innej nie naszej schemie, aczkolwiek nawet procedury dodane do ModelDanychContainer raczej przetrwają aktualizację. Czy jest Pan pewien, że ta procedura zniknęła?

Na tej liście nie ma Instynktu, tylko bardzo proste wyszukiwanie tekstowe. Zobaczymy, co da się tam zrobić, żeby wyszukiwało się lepiej przy wielu podmiotach.

W którym miejscu? W całym nexo domyślne zachowanie Instynktu jest takie, że uruchamia się dopiero po podaniu dwóch znaków.

Proszę spróbować z plikami startowymi. Tworzy się je w programie serwisowym nexo i można w nich podać namiary na serwer oraz podmiot. Takie pliki są domyślnie otwierane przez InsLauncher.exe, można też uruchamiać je przy pomocy polecenia: "C:\Program Files (x86)\InsERT\nexo\InsLauncher.exe" /StartupFile={ścieżka do pliku startowego} Po uruchomieniu z podanym plikiem startowym InsLauncher uruchomi odpowiedni program z linii nexo wg tego, co wskazano w polu 'Scenariusz'.

Chciałabym, żeby dla osób czytających ten wątek było jasne, że InsERT nie zaleca pracy z jakimkolwiek programem z linii nexo na niewspieranych systemach operacyjnych. Tymczasowo da się to jeszcze robić, natomiast od wiosny 2024 nowe wersje nexo nie będą się instalować i uruchamiać na stanowiskach niespełniających wymagań co do wersji systemu operacyjnego i SQL Servera. Informowaliśmy o tym już wcześniej:

Czy ten problem dotyczy którejś z nexowych aplikacji czy występuje w rozwiązaniu sferycznym? Jeśli w rozwiązaniu sferycznym, to w wersji 47 będzie to poprawione.

No właśnie nie mamy łatwego dostępu Dziękuję za wyjaśnienia - zobaczymy, co da się zrobić!

To ja jeszcze podrążę, bo nie do końca rozumiem problem. Wyobrażam sobie, że ma Pan dwa pakiety, np. Kopytko-1.0.0.0 i Kopytko-2.0.0.0 i w obydwu znajduje się aplikacja Kopytko.exe. Czy chciałby Pan, żeby Kopytko.exe po uruchomieniu potrafiło powiedzieć, czy pochodzi z pakietu 1.0.0.0 czy z 2.0.0.0? Bo jeśli tak, to nie mam dobrych wieści, bo nie za bardzo da się to zrobić. Znaczy da się, ale trzeba by sprawdzać wszystkie pakiety podpięte do podmiotu i patrzeć, czy jest w nich Kopytko.exe i wtedy można zgadywać, że ten właśnie pakiet jest źródłem tego właśnie pliku. To jest taka droga trochę okrężna. Czy nie byłoby łatwiej, gdyby wersjonował Pan swoją aplikację przy pomocy atrybutu AssemblyVersion i wtedy mógłby Pan ją sam sprawdzać i wyświetlać?

Jeśli jest to SDK starszej niż 41.2.1, to może to wynikać z tego, że na komputerze jest zainstalowany .NET Framework w wersji 4.8.1. Starsze wersje Sfery nie działają na tej wersji .NETa. Więcej informacji tutaj:

Czy może Pan przytoczyć, jaki to był błąd? Sprawdzanie FlagaWlasna.Id to jak najbardziej słuszna droga postępowania, ale należy mieć na uwadze, że jeśli dokument nie ma flagi, to FlagaWlasna będzie nullem i wtedy odwołanie się do pola Id spowoduje błąd NullReferenceException.

Przykro mi, ale nie będziemy tu nic zmieniać.

Tak, można używać UI nexo w aplikacja Windows Forms. Wymaga to jednak utworzenia instancji typu AplikacjaWpf, który dziedziczy po WPFowym Application. Nie trzeba nic z tą instancją robić, wystarczy jedynie, żeby zainstniała przed utworzeniem Uchwytu. Poniżej zamieszczam mały przykład, w którym w aplikacji Windows Forms otwierane jest okno konkretnego towaru: public partial class Form1 : Form { private Uchwyt _sfera; public Form1() { InitializeComponent(); } private void buttonPolacz_Click(object sender, EventArgs e) { // utworzenie instancji aplikacji WPFowej var app = new AplikacjaWpf(); _sfera = Uchwyty.NowyZDostepemDoUi(); } private void buttonPokaz_Click(object sender, EventArgs e) { if (_sfera != null) { var asortymenty = _sfera.Asortymenty(); var asortyment = asortymenty.Znajdz("PESO20"); if (asortyment != null) { var okno = _sfera.PodajObiektTypu<IAsortymentOkno>(); okno.Pokaz(asortyment); } else { _ = MessageBox.Show("Nie udało się odnaleźć towaru o symbolu \"PESO20\""); } } } }

Co ma Pan na myśli, pisząc "dłuższa bezczynność"? Czy przy takim zawieszeniu widać w menadżerze zadań zwiększone zużycie pamięci przez proces nexo (powyżej 1 GB)?

Czerwonego paska z informacją o niespełnionych wymaganiach systemowych nie da się wyłączyć i nie będziemy tego zmieniać. Producent Windowsa 7 zakończył wsparcie dla tego systemu 14 stycznia 2020. Od tamtego czasu InsERT nexo oficjalnie nie jest przeznaczone na komputery z tym systemem. Informowaliśmy o tym w odpowiednim czasie: https://www.insert.com.pl/aktualnosci/informacje/2020/koniec_wsparcia_dla_starszych_systemow.html. Od tamtej pory zresztą samo nexo wyświetla komunikaty o tym, że system nie jest wspierany i zalecamy jego aktualizację. To, że w 2023 roku dalej da się pracować na nexo na Windowsie 7, to raczej dzieło szczęśliwego przypadku niż świadomego działania. Z każdą kolejną wersją nexo rośnie prawdopodobieństwo, że to szczęście się wyczerpie i coś w programie przestanie działać, czy to z winy Microsoftu, czy to innego dostawcy albo jakiegoś malware'u celującego w stare systemy operacyjne. Nie mamy nad tym kontroli i nie chcemy, aby nasi użytkownicy znaleźli się w sytuacji, w której nagle nie mogą pracować na nexo z powodu awarii związanej z systemem operacyjnym. Dlatego zdecydowaliśmy się informować o niespełnionych wymaganiach systemowych przy pomocy bardziej zdecydowanego środka wyrazu, którym jest czerwony pasek, a docelowo uniemożliwimy instalację i aktualizację nexo na niekompatybilnych komputerach. Informacja o tym została podana jakiś czas temu: Odcięcie Windowsa 7 nastąpi wiosną 2024, więc zostało jeszcze sporo czasu, żeby zaktualizować komputery. Bardzo do tego zachęcam.

Flagi zostały dodane do raportów SQL w wersji 41.

Proszę sprawdzić wersję .NET Framework. Odnośnik do instrukcji dodałam w poprzednim poście. Jeśli to wersja 4.8.1, to należy postępować zgodnie z podanymi wcześniej sugestiami. Może się Pan również zgłosić z tym problemem przez formularz kontaktowy, dostępny pod adresem https://www.insert.com.pl/dla_uzytkownikow/formularz_kontaktowy.html.

Proszę sprawdzić, czy nie ma Pan przypadkiem zainstalowanego .NET Framework 4.8.1 - objawy do tego pasują. Nexo w wersji starszej niż 41.2.1 nie uruchamia się na komputerach, które mają zainstalowaną tę wersję .NET Frameworka. Jeśli tak, to rozwiązania są dwa: zmienić .NET Framework na wersję 4.8, zaktualizować nexo do nowszej wersji (zalecane). Jak sprawdzić wersję .NET Framework: https://learn.microsoft.com/en-us/dotnet/framework/migration-guide/how-to-determine-which-versions-are-installed Wątek, w którym informowaliśmy o tym problemie:

Moglibyśmy wyrzucać takie sesje z bazy, gdybyśmy wiedzieli, że końcówka, z której pochodzą, jest uśpiona albo w jakiś inny sposób nieaktywna, bo inaczej ryzykujemy, że program będzie się wysypywał z powodu brakujących sesji. Aktualnie nexo nie jest w stanie tego sprawdzić i nie sądzę, żeby w najbliższych wersjach się to zmieniło. Nie, aktualnie nie jesteśmy w stanie tego zrealizować.

Zgadzam się, że mogłyby być bardziej jednoznaczne. Jeśli komputer jest uśpiony, to przeszkodą są tylko ewentualne sesje aplikacyjne w nexo uruchomionym na takim uśpionym komputerze. Sesje aplikacyjne wygasają po 6 minutach, więc po upływie tego czasu uda się zrobić konwersję. Gdy uśpiony komputer zostanie wybudzony, nexo na tym komputerze wykryje, że jest w innej wersji niż wersja bazy i się zamknie.

Poniżej wklejam zrzut ekranu z programu serwisowego - takie ustawienie blokady spowoduje, że wszystkie stacje robocze wyłączą się same bez pytania po 5 minutach, pod warunkiem, że komputer nie jest uśpiony. Jeśli zaznaczy się opcję 'wyświetl komunikat', to program na końcówce wyświetli komunikat i będzie czekał, aż użytkownik kliknie OK. Jeśli się tej opcji nie zaznaczy, to wyłączenie nastąpi bez interakcji z użytkownikiem. Sądzę, że to rozwiązuje problem. Jeśli ustawił Pan blokadę w taki sposób i nie zadziałała, to proszę o przysłanie logów z komputera, na którym ustawiono blokadę, oraz z tej stacji roboczej, która się nie zamknęła, żebyśmy mogli zdiagnozować, co poszło nie tak. Tutaj znajdzie Pan informacje o tym, jak zebrać logi: https://www.insert.com.pl/dla_uzytkownikow/e-pomoc_techniczna/2158,insert-nexo-–-jak-wygenerowac-dane-diagnostyczne.html.

A czy może Pan trochę bardziej szczegółowo opowiedzieć o okolicznościach występowania błędu? Np. czy używa Pan naszych szablonów do VS? czy buduje Pan swoje rozwiązanie do domyślnego katalogu, który ustawia się w VS, czy może do innego folderu? skąd się wzięło sgd.pak w folderze wyjściowym Pana aplikacji? Standardowo nie powinno go tam być. czy komunikat na pewno dotyczy sgd.pak, a nie jakiegoś innego pliku (xaml.pak, xsd.pak, itp.)? Sgd.pak nie jest potrzebny do drukowania, natomiast potrzebny jest Mrt.pak. Powinien się on znaleźć w katalogu wynikowym aplikacji, ale nie trafia tam automatycznie, więc będzie go brakowało. Można go tam kopiować w ramach zdarzenia post-build. Jeśli korzysta Pan z naszych szablonów, to można zrobić tak:

Czy ten błąd występuje podczas uruchamiania tego kodu w Visual Studio, czy już po wdrożeniu rozwiązania w podmiocie?

Kompaktowanie zmienia rozmiar pliku tak, żeby po kompaktowaniu było w nim tyle procent wolnego miejsca, ile podaje Pan w zaznaczonym polu. Proszę zwrócić uwagę na to, że plik, który próbuje Pan tu kompaktować, ma aktualnie 1,36% wolnego miejsca (plik zaznaczony jest w tabelce, a wolne miejsce jest w kolumnie 'Wolne miejsce (%)'. Skoro przed operacją jest 1,36% wolnego miejsca, a po operacji ma być 10% wolnego miejsca, to można to osiągnąć jedynie powiększając plik i stąd te prognozowane 4008 MB. Kompaktowanie ma sens tylko w sytuacjach, gdy w pliku jest dużo wolnego miejsca. Na przykład u Pana w pliku logu (ten z koncówką "_log") jest ponad 98% wolnego miejsca. Plik ma 520 MB, ale faktycznie zajęte jest tylko niecałe 10, więc wydaje się, że można by go spokojnie przyciąć o 500 MB. A przynajmniej tak jest w teorii, bo w praktyce należy się spodziewać, że ten plik z czasem urośnie z powrotem, więc nie jest to bardzo skuteczna metoda na odchudzanie bazy.