Katarzyna Rozmarynowska

Najmocniej przepraszam, zapomniałam dodać informację o tej zmianie tutaj na forum. Już dodaję: Zmiany w Bibliotece. Usunięcie tych interfejsów planujemy na wersję 36 lub później, ale na pewno nie wcześniej. Dokumentacja SDK zawiera informację o IBibliotekaZalacznikow i innych nowych interfejsach od wersji 33.0.0. W wyniku błędu w wersji 33.0.0 brakowało w pomocy podrozdziału z przykładami użycia tych nowych komponentów, ale w wersji 33.0.1 zostało to poprawione (Przykłady -> Nowa biblioteka załączników).

W wersji 33.0.0 we wszystkich programach linii InsERT nexo udostępniliśmy w Laboratorium nową wersję "Biblioteki załączników". Z punktu widzenia użytkownika nowa Biblioteka zawiera niewielkie poprawki, jednak zaszły tam istotne zmiany w modelu danych i sferycznym API, dlatego bardzo zachęcam do zapoznania się z tymi zmianami, zwłaszcza wszystkich twórców rozwiązań własnych. 1. Co się zmieniło? W starej wersji Biblioteki jeden załącznik był powiązany z dokładnie jednym obiektem w programie nexo. Jeśli użytkownik chciał powiązać ten załącznik z innym obiektem, to musiał go dodać drugi raz. To prowadziło do powstawania duplikatów, które niepotrzebnie zajmowały miejsce w bazie danych. Jeśli użytkownicy edytowali załączniki, to te duplikaty mogły się potem różnić, co było dodatkową niedogodnością. W nowej wersji Biblioteki jeden załącznik może być powiązany z wieloma obiektami w programie i ma w bazie tylko jeden egzemplarz. Nie można dodać do Biblioteki załącznika o takiej samej nazwie, rozszerzeniu i zawartości. W widoku "Biblioteka załączników" można wylistować wszystkie obiekty podłączone do danego załącznika, a także odłączyć - niektóre z nich lub od razu wszystkie. Na poziomie sferycznego API wprowadziliśmy następujace zmiany: * dotychczasowe interfejsy związane z obsługą Biblioteki, IObiektBibliotekiDokumentow, IObiektyBibliotekiDokumentow oraz IObiektyBibliotekiDokumentowDane, zostały oznaczone jako Obsolete, * udostępniliśmy nowy interfejs do obsługi Biblioteki, IBibliotekaZalacznikow, który na razie współpracuje z obiema wersjami Biblioteki. 2. Kiedy nowa Biblioteka będzie dostępna poza Laboratorium i co się stanie ze starą Biblioteką? Planujemy, że w wersji 36.0.0 przeprowadzimy u wszystkich użytkowników automatyczną migrację na nową wersję Biblioteki. Opcja zmiany wersji Biblioteki zniknie z Laboratorium. Związane ze starą Biblioteką elementy API zostaną usunięte. Być może nastąpi to później, ale na pewno nie wcześniej. 3. Jak włączyć nową Bibliotekę? Aby włączyć nową Bibliotekę, należy wcisnąć Ctrl+Spacja+XX, zaakceptować regulamin Laboratorium i kliknąć "Włącz" w sekcji "Nowa biblioteka załączników". Następnie należy się przelogować lub uruchomić nexo ponownie. Przed włączeniem Biblioteki zalecamy zrobienie kopii zapasowej. 4. Mam rozwiązanie własne korzystające z Biblioteki. Co muszę zrobić? W rozwiązaniach własnych w miejscach, gdzie używane są typy związane ze starą Biblioteką (takie jak IObiektBibliotekiDokumentow, IObiektyBibliotekiDokumentow, IObiektyBibliotekiDokumentowDane, ObiektBibliotekiDokumentow), należy zamiast nich użyć typu IBibliotekaZalacznikow i innych, takich jak IZalacznikWBibliotece czy IObiektPowiazanyZZalacznikiem. Interfejs IBibliotekaZalacznikow współpracuje z obiema wersjami Biblioteki. To oznacza, że jeśli w danej bazie nie włączono jeszcze nowej Biblioteki, to rozwiązanie własne i tak może zostać zaktualizowane tak, żeby korzystać z nowego interfejsu. Po zaktualizowaniu rozwiązania własnego można włączyć nową Bibliotekę w Laboratorium albo poczekać na aktualizację nexo, która sama zmieni wersję Biblioteki. IBibliotekaZalacznikow wykryje tę zmianę i dostosuje do niej swoje działanie. Przykłady użycia nowych interfejsów można znaleźć w pomocy do Sfery od wersji 33.0.1.

Potwierdzam, takie zachowanie jest powtarzalne. Będziemy pracować nad poprawką, prawdopodobnie do wersji 35.

Dokładniej mówiąc, to gdy pakiety danej wersji są dłużej nieużywane, to podczas uruchamiania nexo je usuwa bez pytania. Pytanie, które czasem się pojawia, dotyczy kompaktowania bazy InsERT_Launcher, w której przechowywane są pakiety. Po usunięciu tych nieużywanych zostaje w niej dużo wolnego miejsca i można to skompaktować, żeby i baza zajmowała mniej. Jeśli chodzi o foldery podmiotów w katalogu Deployments, to chciałabym zwrócić uwagę na istotny fragment zalinkowanego wyżej artykułu e-pomocy: To jest bardzo istotne: pliki w folderze podmiotu są tak naprawdę linkami i zajmują bardzo mało miejsca, ale jeśli zajrzymy w ich właściwości, to system podaje tam rozmiar oryginalnego pliku, przez co wydaje się, że zajęte już dużo więcej miejsca niż w rzeczywistości. Weźmy taki przykład: mam dwa podmioty w wersji 32.0.0. Na poniższym zrzucie ekranu z menadżera plików widać ich katalogi w folderze Deployments. Każdy zajmuje ponad 900 MB. Liczba zaznaczona na żółto to wolne miejsce na moim dysku P. Usuwam oba katalogi. Jeśli oba miały ponad 900 MB, to ilość wolnego miejsca na moim dysku powinna się zwiększyć o prawie 2 GB. Tymczasem wygląda to tak: Katalog jest pusty, a wolne miejsce zwiększyło się o mniej niż 1 MB. To dlatego, że usunięte obiekty były hardlinkami, a nie prawdziwymi plikami. Przed ich usunięciem sprawdziłam to przy pomocy narzędzia fsutil. Poniższy zrzut pokazuje wszystkie twarde dowiązania do pliku Subiekt.exe, który mam w .zip-cache: To wyjaśnia, dlaczego usuwanie tych katalogów nie zwalnia tyle miejsce, ile się człowiek spodziewa. Tak jak pisała powyżej Pani Agnieszka: U Pani Agnieszki zwolniło się trochę więcej miejsca, co prawdopodobnie wynika z tego, że w moim przypadku katalogi Config i Work (np. P:\deployments\Nexo\Demo_1678c005103494c7b8a5b78b5be\Config) były zupełnie puste, a u Pani Agnieszki prawdopodobnie coś tam się uzbierało podczas pracy z programem. Pliki w Config i Work są "prawdziwymi" plikami, a nie linkami. Zdaję sobie sprawę z tego, że dla osoby, która zmaga się z brakiem miejsca na dysku, powyższe wyjaśnienie jest ciekawostką i nie rozwiązuje żadnego problemu. Wiem, że zmniejszenie rozmiaru katalogu Deployments to dla wielu użytkowników bardzo ważna kwestia i zapewniam, że szukamy sposobu na jej rozwiązanie w sposób, który nie zaburzy funkcjonowania programu. Na ten moment mogę jedynie zalecić, żeby pozwolić programowi automatycznie usuwać nieużywane pakiety, co pozwoli przynajmniej na to, żeby na dysku nie gromadziły się binaria ze starszych wersji programu. Są one usuwane z katalogu C:\ProgramData\InsERT\Packages\, z katalogu .zip-cache i z bazy dystrybucyjnej. Żeby ta operacja działała optymalnie, program musi mieć możliwość stałego śledzenia użycia pakietów i w związku z tym, jeśli czyszczą Państwo te lokalizacje samodzielnie (tzn. inaczej niż za pomocą programu serwisowego), to najlepiej jest pozostawić w folderach ProgramData i .zip-cache katalogi PackageCleaner i PackageCacheCleaner.

Niestety, nie udało mi się powtórzyć tego problemu z RadRibbonWindow. Zadziałał u mnie taki kod: class AplikacjaStartowa : AplikacjaWpf { [STAThread] static void Main(string[] args) { var appStart = new AplikacjaStartowa { StartupUri = new System.Uri("MainWindow.xaml ", System.UriKind.Relative), ShutdownMode = System.Windows.ShutdownMode.OnLastWindowClose }; appStart.Uruchom(); } } <telerikRibbon:RadRibbonWindow x:Class="Sfera_telerik_wpf.MainWindow" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:d="http://schemas.microsoft.com/expression/blend/2008" xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:telerikRibbon="clr-namespace:Telerik.Windows.Controls;assembly=Telerik.Windows.Controls.RibbonView" mc:Ignorable="d" Title="MainWindow" Height="450" Width="800"> <Grid> <Grid.RowDefinitions> <RowDefinition Height="Auto" /> <RowDefinition Height="*" /> </Grid.RowDefinitions> <telerikRibbon:RadRibbonView x:Name="RibbonView" Grid.Row="0" ApplicationName="Aplikacja sferyczna z Telerikiem" > <telerikRibbon:RadRibbonView.Items> <telerikRibbon:RadRibbonTab Header="Jeden" /> <telerikRibbon:RadRibbonTab Header="Dwa" /> <telerikRibbon:RadRibbonTab Header="Trzy" /> </telerikRibbon:RadRibbonView.Items> </telerikRibbon:RadRibbonView> <Button x:Name="UruchomSfereButton" Content="Uruchom Sferę" Click="UruchomSfereButton_Click" VerticalAlignment="Center" HorizontalAlignment="Center" Grid.Row="1"/> </Grid> </telerikRibbon:RadRibbonWindow> public partial class MainWindow : RadRibbonWindow { public MainWindow() { InitializeComponent(); } private void UruchomSfereButton_Click(object sender, RoutedEventArgs e) { var uchwyt = UruchomSfere(); _ = MessageBox.Show("Sfera została uruchomiona"); } static Uchwyt UruchomSfere() { DanePolaczenia danePolaczenia = DanePolaczenia.Jawne("(local)", "nexo_31_1_2", true); MenedzerPolaczen mp = new MenedzerPolaczen(); mp.DostepDoUI = true; Uchwyt sfera = mp.Polacz(danePolaczenia, ProductId.Subiekt); _ = sfera.ZalogujOperatora("Szef", "robocze"); return sfera; } }

Prawdopodobnie tworzy Pan uchwyt przed utworzeniem instancji aplikacji WPF. Zgodnie z instrukcją do SDK, należy najpierw utworzyć aplikację, tj. obiekt klasy dziedziczącej po klasie AplikacjaWpf, uruchomić ją przy pomocy metody Uruchom(), a dopiero potem utworzyć uchwyt.

Czy może Pan opisać, jak wyglądało to niepowodzenie? Korzystanie z InsERT.Mox.EntityFramework.Core.dll bez referencji do EntityFramework jest możliwe. Jeśli w projekcie była ta referencja do EntityFramework i została usunięta, to proszę się upewnić, że w pliku App.config nie ma sekcji konfiguracji o nazwie "entityframework". Jeśli tam jest, to można ją usunąć lub zakomentować i spróbować jeszcze raz. Jeśli to nie zda egzaminu i zależy Panu na tym, żeby naprawdę załadować do jednej aplikacji dwie wersje EF, to można jeszcze spróbować zmian konfiguracji opisanych tutaj albo ładowania jednej z wersji biblioteki w osobnej domenie aplikacyjnej.

Ok, to czekamy na rozwój sytuacji.

A czy może Pan sprawdzić, jaki proces używa tego pliku? Np. za pomocą Process Explorera.

Przepraszam, że dopiero teraz odpisuję, ale ten wątek jakoś mi umknął. Jak dotąd nie mieliśmy w planach wprowadzać takiej opcji, ale uwzględnimy Pana sugestię w planowaniu kolejnych wersji nexo.

Wersja 29 wyjdzie prawdopodobnie w lutym.

Logi być może nie będą potrzebne. Udało nam się powtórzyć scenariusz, w którym występuje taki błąd - pojawia się on w widokach "sąsiadujących" w module z widokiem, który jest przywracany z poprzedniej sesji po uruchomieniu programu. W takiej sytuacji można przywrócić brakujące opcje w F8, zamykając cały moduł (tzn. zakładkę z modułem) i otwierając go od nowa. Jeśli to nie pomoże, to poproszę o logi. Błąd - przynajmniej w tym scenariuszu, w którym udało nam się go powtórzyć - będzie poprawiony w wersji 29.

Wersja musi być i to niestety w tym kilkuliczbowym formacie, więc raczej: "SferaNEXO-1.0.0.0".

W polu "Nazwa i wersja" musi być podana nazwa i wersja, oddzielone myślnikiem (np. "SferaNEXO-1.0.0.0"). To jest jedyny prawidłowy format, a podanie wartości w nieprawidłowym formacie powoduje, że używana jest poprzednia prawidłowa wartość. Program serwisowy niestety nic tu nie podpowiada, więc to na pewno jest do poprawienia z naszej strony, ale pomijając niedostatki walidacji - wszystko jest tu w porządku. Dodam, że numer wersji, który podaje się obok nazwy rozwiązania własnego, to numer wersji tego rozwiązania, a nie nexo. Numer wersji nexo można podać w polu "Do produktu", np. "Nexo-27.1.0.3175" - będzie to oznaczało, że rozwiązanie własne ma działać tylko z nexo w wersji 27.1.0.3175.

Z bazą naprawdę jest wszystko w porządku, pozostaje więc jedna możliwość: w nowej wersji rozwiązania własnego należy zmienić referencję do InsERT.Moria.ModelDanych.dll, bo baza ma zaawansowane pola własne i ma inny model danych niż ten, który dostarczany jest w SDK. Opisano to w pomocy do Sfery:

Na pewno będziemy rozważać, jak przyspieszyć wczytywanie danych na listach, ale nie jestem w stanie powiedzieć, czy poskutkuje to wprowadzeniem akurat takiej opcji.

Prawdopodobnie poprawkę będzie można zrobić skryptem SQL, więc chyba nie ma potrzeby zatrzymywania pracy.

Ok, w takim razie prawdopodobnie w bazie jest jakaś niedokończona aktualizacja. Proszę spróbować uruchomić nexo na tej bazie - aktualizacja powinna się sama z siebie dokończyć (jak już dojdzie do ekranu logowania użytkownika, to można uznać, że jest po aktualizacji). Jeśli po tym rozwiązanie własne dalej nie będzie działać albo jeśli uruchomienie nexo się nie powiedzie, proszę o przysłanie bazy albo namiaru na bazę do naprawy do Insertu, najlepiej przy pomocy formularza kontaktowego.

Nie ma takiej opcji w nexo. Jeśli chodzi ogólnie o wydajność na listach uruchamianych przez F2, to jest to znany problem, który usiłujemy rozwiązać.

Pakiety po aktualizacji wyglądają zupełnie normalnie, mają prawidłowe numery wersji. Jeśli więc baza jest w porządku, to pozostaje jedno wytłumaczenie: Sfera jest w złej wersji. Proszę się upewnić, że sferyczne biblioteki, do których odwołuje się Pana aplikacja, na pewno są z SDK wersji 27.

Nie mamy obecnie opcji automatycznego odświeżania widoków, ale planujemy ją dodać, prawdopodobnie w wersji wiosennej.

Odpowiedź na pytanie 1: Tak, to pewnie program serwisowy. Blokada bazy jest "przypisana" do procesu. Więc jeśli proces 123 na komputerze X blokuje bazę, to tylko ten proces na tym komputerze ma do niej dostęp. Jeśli ten proces zostanie zakończony, to baza staje się dostępna dla innych procesów na tym komputerze (ale z innych komputerów ciągle nie można się łączyć). Pisząc "procesy" mam na myśli procesy związane z programami nexo, a nie dowolne. Odpowiedź na pytanie 2: Może być. Dla świętego spokoju lepiej go wyłączyć na czas aktualizacji. I. Gdy blokuje Pan bazę na jednym komputerze, użytkownicy na innych komputerach dostają informację o tym, że program zostanie zamknięty za pewien okres czasu. Jeśli nie potwierdzą tej informacji, to program się nie zamknie (bo nie chcemy, żeby użytkownik, który np. odszedł na chwilę od komputera, stracił niezapisaną pracę). Program musi być zamknięty, żeby nexo na pewno nie łączyło się z bazą. II. Gdyby ten komunikat zawierał numer procesu, to wszystko byłoby jasne - nie może Pan aktualizować bazy w procesie X, bo została zablokowana przez Pana w procesie Y. Jeśli chodzi o długi czas sprawdzania, czy ktoś jest połączony - tak naprawdę to odbywa się bardzo szybko, a te 20 minut to raczej czas tworzenia automatycznej kopii zapasowej przed aktualizacją. Sugeruje to rozmiar bazy. Możliwe, że w przyszłych wersjach będziemy sprawdzać połączenia przed wykonaniem kopii.

Niestety, nie mamy w notesie kosza. Na razie też nie mamy w planach dodawania tam nowych funkcji. Gdyby jednak plany miały się zmienić, z pewnością uwzględnimy Pana sugestie.

Mamy w planach umożliwienie podłączania jednego załącznika do wielu obiektów/dokumentów (bez duplikowania załącznika), w pakiecie z opcją wyświetlania listy obiektów, do których załączony jest wybrany plik. Wstępny termin to przyszły rok - i na tym etapie nie jestem w stanie podać nic bardziej konkretnego.

Wygląda na to, że napisałam nieprawdę w moim poprzednim poście i jest dokładnie tak, jak Pan opisuje, tzn. Launcher nie znajduje scenariusza, jeśli nie podepnie się pakietu do bazy. Bardzo przepraszam za to nieporozumienie. Tak wygląda pakiet z rozszerzeniem własnym podpięty do bazy Demo_1: Pakiet MojeRozszerzenieEXE zawiera aplikację WpfApp1.exe, uruchamianą w scenariuszu WpfApp1. Uruchamiam InsLaunchera z parametrem Nexo/WpfApp1: Tak wygląda proces z moją aplikacją: Wpis w polu "Do produktu" ma znaczenie dla "długości życia" rozwiązania własnego. Jeśli poda tam Pan Nexo-26.2.1.3077, to rozwiązanie będzie działało tylko z bazami w wersji 26.2.1.3077, a po aktualizacji bazy do innej wersji zostanie odłączone. Jeśli nie poda Pan tam nic, to rozwiązanie, raz przypięte do bazy, będzie do niej przypięte już zawsze, tzn. będzie je można ręcznie odpiąć w programie serwisowym, ale nie odłączy się samo w trakcie aktualizacji. Jeśli chodzi o bazę InsERT_Launcher, to nie ma ona wersji i jest to zupełnie normalne.