Katarzyna Rozmarynowska

Czy przy pakowaniu rozwiązania podał Pan scenariusz uruchomienia? InsLauncher.exe uruchamiany jest z parametrami {Produkt}/{Scenariusz}, gdzie {Produkt} to nexo, a {Scenariusz} to w Pana przypadku "WPFApplication". Wobec tego przy pakowaniu rozwiązania własnego w programie serwisowym w zakładce "Uruchamianie" należy dodać do listy scenariusz o nazwie "WPFApplication" i podać, jaka aplikacja ma być uruchamiana w tym scenariuszu (np. "WPFApplication.exe"). Tak przygotowane rozwiązanie własne może Pan uruchomić teoretycznie na dowolnej bazie nexo i nie ma potrzeby dodawania pakietu z tym rozwiązaniem do listy pakietów składowych w wybranej bazie. Na takiej samej zasadzie nie trzeba tam nic dodawać, żeby np. na bazie z Subiektem uruchomić Gratyfikanta - wystarczy uruchomić scenariusz Nexo/Gratyfikant. Rozwiązanie własne trzeba dodać do listy pakietów składowych wtedy, gdy nie jest osobną aplikacją i jest uruchamiane w ramach jakiegoś istniejącego scenariusza. Na przykład: jeśli mam rozwiązanie własne "MojeRozszerzenie.dll" i chcę, żeby działało w bazie Demo_1, to pakuję je do mpkg (MojeRozszerzenieDLL-26.2.1.3077.mpkg), podpinam na liście pakietów składowych bazy Demo_1 i uruchamiam Nexo/Subiekt na bazie Demo_1. InsLauncher wczytuje wtedy wszystkie pakiety składowe bazy Demo_1, w tym zawartość mojego pakietu MojeRozszerzenieDLL-26.2.1.3077.mpkg. Jeśli natomiast mam osobną aplikację, "MojeRozwiązanie.exe", to też pakuję je do mpkg (MojeRozszerzenieEXE-26.2.1.3077.mpkg). Podaję scenariusz o nazwie "MojScenariusz", w którym uruchamiana jest aplikacja "MojeRozwiazanie.exe" i nie podłączając rozwiązania do bazy Demo_1, mogę je uruchomić InsLauncherem z parametrem Nexo/MojScenariusz. Tutaj przyznam, że chyba nie do końca rozumiem dokładnie Pana problem, ale chcę zauważyć, że wersja programu i wersja SDK użytego do stworzenia rozwiązania własnego muszą się zgadzać, więc możliwe, że musi Pan po prostu aktualizować rozwiązanie własne razem z nexo.

Na obecnym etapie prac jeszcze nie za bardzo.

Jest to niestety skutek uboczny synchronizacji między bazą a dyskiem (bo po otwarciu plik jest zapisywany na dysku). Nie ma na to żadnego obejścia. Poprawki można się spodziewać w jednej z przyszłych wersji, prawdopodobnie w pakiecie z innymi zmianami w bibliotece.

Zamierzamy dodać taką opcję, ale nie jestem w stanie powiedzieć, kiedy to zrobimy. Obawiam się, że raczej nie w tym roku. Niestety, dokładnie tak jest. Naprawa tego błędu prawdopodobnie będzie robiona w pakiecie z otwieraniem obiektu docelowgo.

A czy mógłby Pan jeszcze napisać, jakie dokładnie uprawnienia ma ten użytkownik?

To w takim razie proszę zajrzeć do %localappdata%\InsERT\Logs\ i zobaczyć, czy zapisał się tam jakiś błąd (w pliku .xml). Bez szczegółowych informacji trudno powiedzieć, co się dzieje.

Czy ten użytkownik ma przyznane uprawnienie "View server state"?

Dziękuję za informacje. Naprawimy, jak tylko uda nam się to powtórzyć.

Jeśli to jest Subiekt z Gratyfikantem (a nie Gratyfikant z Subiektem), to właściwa lista zapamiętanych zakładek powinna się pojawić po wykonaniu: SELECT * FROM ModelDanychContainer.StanyAplikacji WHERE Klucz = 'OpenServices.Subiekt'.

To wygląda na błąd. Chciałabym napisać, że go poprawimy, ale na razie nie udało się go powtórzyć. Trochę pytań dodatkowych: - czy to są wszystkie raporty z tej bazy czy jakiś losowy podzbiór? - czy te raporty (włącznie z wybranym) są podpięte jako widoki w jakimś module? - co jest w historii zakładki po starcie programu? (Można to sprawdzić w bazie: SELECT * FROM ModelDanychContainer.StanyAplikacji WHERE Klucz = 'OpenServices.Gratyfikant')

Mogę to opisać, ale chcę zastrzec, że zdecydowanie nie polecam kompaktowania bazy. Tak jak pisze pan Andrzej, ta operacja na ogół nie ma sensu, bo miejsce, które się zwolni przy kompaktowaniu, wkrótce zostanie i tak znowu zajęte, w miarę jak w bazie będzie przybywać danych. Istnieje natomiast pewne ryzyko, że kompaktowanie spowolni pracę bazy. W sumie więc nie warto tego robić dla chwilowego odzyskania kilku gigabajtów. Jeśli jednak chce Pan podjąć to ryzyko, oto instrukcja: w SQL Server Management Studio proszę wybrać bazę, kliknąć na niej prawym przyciskiem myszy i wybrać Tasks -> Shrink -> Database. Pokaże się okienko, w którym napisane będzie, ile wolnego miejsca jest w bazie. Żeby ją skompaktować, wystarczy kliknąć OK. Szczegóły w dokumentacji.

Nie widzę przeciwwskazań.

Niestety, aktualna wersja nexo nie oferuje żadnych ułatwień, jeśli chodzi o kompaktowanie baz. W wersji jesiennej pojawi się opcja kompaktowania w programie serwisowym nexo. Tymczasem można skompaktować bazę samemu, korzystając z aplikacji SQL Server Management Studio lub z innego programu umożliwiającego wykonywanie zapytań SQL. Jeśli zdecyduje się Pan na taką operację, to po jej zakończeniu zalecam wykonanie konserwacji bazy w programie serwisowym - pomoże to zredukować negatywne skutki kompaktowania bazy.

Obawiam się, że w tej chwili nie mamy na to żadnej rady. Dopóki nie umożliwimy w bibliotece podłączania alternatywnych miejsc przechowywania danych (w chmurze czy gdzie indziej), to nie będzie się dało tego rozwiązać. Rozważamy taką opcję, żeby umożliwić tam dodawanie własnych pluginów łączących z miejscem przechowywania plików. Pana sugestie są oczywiście bardzo słuszne, ale zdjęcia towarów są w tej chwili odrębnym bytem i nie jestem w stanie udzielić tu konkretnej odpowiedzi. Możliwe, że w przyszłości będziemy chcieli je włączyć do biblioteki załączników i wtedy owszem, wszystkie nowe funkcje biblioteki będą dostępne także w zdjęciach towarów.

Rozważamy to, ale nie mamy jeszcze konkretnych planów.

Czy może Pan opisać problem bardziej szczegółowo? W jaki sposób nadaje Pan flagę: przez kliknięcie na liście operacji kasowych, przez menu kontekstowe na liście, czy może podczas edycji/podglądu konkretnej operacji? Co dokładnie znaczy "nie działa"? Nic się nie dzieje, czy pokazuje się jakiś komunikat o błędzie? Czy nadawanie flag w innych widokach także nie działa, czy problem występuje tylko przy operacjach kasowych?

Wygląda na to, że doszło do jakiejś kolizji między nexo a - jak przypuszczam - jakimś rozwiązaniem własnym, które ma Pan zainstalowane. Czy może Pan przesłać pełny raport z aktualizacji? Może go Pan wkleić tutaj lub wysłać zgłoszenie formularzem kontaktowym . Nie zaszkodzi też, jeśli prześle Pan komplet logów z c:\Users\{użytkownik}\AppData\Local\InsERT\InsLauncherLogs i c:\Users\{użytkownik}\AppData\Local\InsERT\Logs.

Wygląda na to, że zepsuły się ustawienia tego widoku. Można je znaleźć w tabeli ModelDanychContainer.WidokiSerwisowe i zidentyfikować po nazwie widoku oraz ID użytkownika, u którego występuje ten problem. Jeśli uda się zidentyfikować widok, to można usunąć rekord. Spowoduje to usunięcie ustawień tego widoku zapisanych dla danego użytkownika; sam widok jest wbudowany w program i zostanie zachowany. Po ponownym zalogowaniu użytkownik powinien zobaczyć ten widok z domyślnymi ustawieniami.

Czy to znaczy, że zmienił Pan SDK z wersji 24.0.1 na 24.0.2? Ten krok jest konieczny. Kopiowanie "InsERT.Moria.ModelDanych.dll" jest potrzebne tylko wtedy, gdy korzysta Pan z pól własnych i z pewnością nie wystarczy, jeśli SDK będzie dalej w wersji 24.0.1.

Baza InsERT_Launcher zawiera tzw. pakiety dystrybucyjne nexo, w których znajdują się wszystkie pliki niezbędne do działania programu. Poza nimi mogą się tam znaleźć pakiety z rozwiązaniami własnymi i jeśli Pan z nich korzysta, to w takim wypadku backupowanie bazy może mieć sens. W przeciwnym razie, jeśli ma Pan tylko standardowe, nexowe pakiety i korzysta z nexo w wersji 17 lub nowszej, to raczej nie ma takiej potrzeby. Gdyby przypadkiem stracił Pan tę bazę, to zostanie ona utworzona na nowo, a brakujące pakiety zostaną pobrane z Internetu. Jeśli martwi Pana rozmiar tej bazy, to jest tu kilka rozwiązań. Przede wszystkim, rozmiar w okoliach 7 GB wskazuje na to, że nazbierało się u Pana trochę pakietów ze starszych wersji programu. Można to po prostu zostawić - program będzie je na bieżąco usuwał, jeśli będą nieużywane. Drugim rozwiązaniem jest skorzystanie z programu serwisowego nexo, który w menu 'Narzędzia' ma opcję 'Usuń pakiety dystrybucyjne', pozwalającą na usunięcie pakietów nieużywanych przez podaną liczbę dni ("baza dystrybucyjna" to baza InsERT_Launcher, a "foldery na tym komputerze" to foldery, do których program rozpakowuje te pakiety dystrybucyjne, a które służą jako cache) . Trzecie rozwiązanie jest drastyczne - można tę bazę po prostu usunąć. Jak napisałam wyżej, przy następnym uruchomieniu programu zostanie ona utworzona na nowo, a brakujące pakiety zostaną pobrane z Internetu.

Sądzę, że w takiej sytuacji można rozważyć użycie mechanizmu FILESTREAM. Instrukcja jego obsługi w połączeniu z nexo zamieszczona jest standardowo w naszym SDK, załączam ją także w tym poście. Wlaczanie_FILESTREAM_-_instrukcja.pdf

Tak, już jest poprawione SDK nexo do wersji 22.

To błąd w SDK nexo. Trwają prace nad udostępnieniem poprawionej wersji.

Czy może pan sprawdzić, jakie błędy zgłasza Sfera? Oto przykładowy kod do sprawdzenia błędów wydruku: private static void DrukujDokument(InsERT.Moria.ModelDanych.DokumentDS dokument, IWydruki manager) { using (IWydruk wydruk = manager.Utworz(InsERT.Moria.Wydruki.Enums.TypWzorcaWydruku.FakturaSprzedazy)) { wydruk.ObiektDoWydruku = dokument; wydruk.Drukuj(); if (!wydruk.OstatniaOperacjaZakonczonaSukcesem) { foreach (var blad in wydruk.PobierzListeBledow()) { // zapisz lub wyświetl błąd } } } }

Poprawka tego błędu znajdzie się w wersji 22.