Katarzyna Rozmarynowska

W wersji 40, która ukaże się na wiosnę, będzie się dało wyliczyć raporty własne SQL i Linq, także z parametrami. Raporty wbudowane ciągle czekają na swoją kolej.

Z przykrością informuję, że nie będzie tego w wersji wiosennej i trudno powiedzieć, w której wersji można się tego spodziewać.

Zapisuję do zrobienia, ale niestety nie zdołamy tego dodać wcześniej niż w wersji wiosennej.

Usuwanie bazy danych jest operacją nieodwracalną, dlatego trochę to utrudniamy, żeby zminimalizować ryzyko, że ktoś "przypadkiem kliknie źle" i niechcący usunie sobie dane. Nie zgadzam się co do tego, że pytanie jest głupie. Przypuszczam, że wiele osób przy usuwaniu bazy będzie chciało usunąć także archiwa, więc im to ułatwiamy. Rozumiem jednak, że Pan akurat ma inne potrzeby, dlatego postaramy się w którejś z przyszłych wersji dać możliwość skonfigurowania tego zachowania.

U Pani Izabeli problemem jest brak pakietów wersji 37. Można to rozwiązać, instalując nexo przy pomocy pełnego instalatora. Wtedy pakiety trafią do folderu C:\ProgramData\InsERT\Packages. Ewentualnie, jeśli komputer jest podłączony do Internetu, to program może sam zaproponować, że ściągnie brakujące pakiety z naszego serwera. U Pana Roberta jest zupełnie inny problem. Pakiety sa już na dysku, ale nie powodzi się przesyłanie ich do bazy danych. Prawdopodobnie występuje tam timeout, czyli operacja przesyłania nie kończy się w wyznaczonym czasie. Jeśli dzieje się to w pracy wielostanowiskowej, to najlepszym rozwiązaniem jest załadowanie tych pakietów do bazy danych na komputerze, na którym jest serwer SQL. Można to zrobić przy pomocy programu serwisowego. W tym celu należy: uruchomić program serwisowy, w menu wybrać Widok -> Pokaż bazy -> nexo oraz InsERT_Launcher, na liście baz wybrać bazę InsERT_Launcher, w menu wybrać Podmiot -> Binaria, w oknie "Binaria w bazie" użyć opcji "Wyślij z tego komputera na serwer" i wybrać do przesłania wszystkie pakiety (pliki mpkg) wersji 37. Jeśli to możliwe, to przed przesłaniem pakietów dobrze jest zrestartować serwer SQL.

To komunikat z wykazu podatników VAT: Nie dotyczy on bazy danych, na której ma Pani uruchomione nexo - z nią jest wszystko w porządku i nie wymaga żadnej naprawy.

Myślę, że najbliższą rzeczą pasującą do tego, o co Pan pyta, są tzw. punkty rozszerznia, czyli przewidziane z góry miejsca w programie, gdzie można wstawić swoje własne funkcje. Ich listę znajdzie Pan w pomocy do SDK nexo w rozdziale "Rozszerzanie - Punkty rozszerzania". Do SDK są też dołączone projekty z przykładami wykorzystania punktów rozszerzania (np. projekt FunkcjaGenerowaniaNaglowkaWydruku). Jeśli szuka Pan możliwości dodania nowych operacji do dowolnego menu w nexo, to niestety nie ma takiej możliwości.

Idealnie tak, należałoby przekompilować rozwiązanie własne, ale istnieje też taka możliwość, że nie zawsze będzie to konieczne. Przykład: mam rozwiązanie własne napisane w oparciu o SDK w wersji 36.1.0 i ono łączy się bez problemu z bazą w wersji 36.1.0, ale z żadną inną już nie. Jeśli jednak wezmę .exe tego rozwiązania i przekopiuję je do folderu, w którym leżą binaria z wersji 36.0.0, to moje rozwiązanie uruchomi się i połączy z bazą w wersji 36.0.0, ale z żadną inną nie. Wynika to z tego, że w tym przypadku podczas uruchamiania mojego rozwiązania załadują się biblioteki z bieżącego folderu, czyli m.in. InsERT.Moria.Sfera.dll z wersji 36.0.0. Warunkiem poprawnego działania takiego rozwiązania jest oczywiście to, że mój program sferyczny korzysta z tylko takich elementów API, które istniały już w wersji 36.0.0. Ze względu na to, że staramy się nie robić tzw. "łamiących zmian" w API, to możliwe jest, że mój program będzie działał z wieloma innymi wersjami SDK - po prostu w trakcie jego uruchamiania załadują się inne biblioteki niż te, których użyłam, gdy je pisałam. .NET Framework 4.8 powinien być wystarczający. Jeśli na komputerze jest zainstalowane nexo, to prawdopodobnie ma on już odpowiednią wersję .NETa, bo gdyby jej nie było, to instalator nexo ją zainstaluje. Jeśli pytając "może to być przyczyną" ma Pan na myśli przyczynę występowania błędu z pierwszego posta, czyli "Podana baza nie jest przystosowana do pracy z nexo, bądź przystosowana jest do wersji innej", to tą przyczyną jest niezgodność wersji bazy z wersją SDK.

Aby rozwiązanie sferyczne działało, musi być zgodność wersji pomiędzy podmiotem, na którym działa rozwiązanie, a SDK, którego użyto przy jego tworzeniu. Jeśli użytko SDK w wersji 35.1.1, to rozwiązanie będzie działać tylko z podmiotami w wersji 35.1.1.

W tej chwili nie za bardzo da się wyliczać raporty w Sferze, ale spróbujemy to umożliwić w jednej z najbliższych wersji.

Mamy zaplanowane wprowadzenie tej opcji w przyszłorocznej wersji wiosennej, o ile oczywiście do tego czasu nie pojawi się coś o wyższym priorytecie.

W takim razie bardzo proszę o wygenerowanie paczki z logami aplikacji (Ctrl+Shift+H -> "Eksportuj informacje diagnostyczne") i podesłanie jej do nas przy pomocy formularza kontaktowego. Idealnie byłoby, gdyby udało się Panu nagrać filmik, w którym widać, co się dzieje z tą kontrolką.

Temat przechowywania plików - zdjęć lub załączników z modułu "Biblioteka załączników" - poza bazą obecnie znajduje się, że tak powiem, w zamrażarce. Przypuszczalnie kiedyś z niej wyjdzie, ale nie mogę podać więcej konkretów. Obawiam się, że nie ma konkretnej odpowiedzi na to pytanie. Wydajność bazy danych zależy od bardzo wielu czynników i nikt tu nie zaryzykuje takiego kategorycznego stwierdzenia, że duża ilość danych w Filestreamie nie ma na nią absolutnie żadnego wpływu. Można zatem pytać o to, jak duży będzie ten wpływ - ale tu też niestety nie ma konkretnej odpowiedzi. Wielkość bazy i jej struktura mają oczywiście znaczenie dla wydajności, ale ta sama baza 50 GB będzie inaczej pracować w zależności od tego, w jakim znajdzie się środowisku. Przez "środowisko" rozumiem nie tylko warunki sprzętowe czy sieciowe, ale także liczbę i aktywność użytkowników, rodzaj wykonywanych przez nich operacji, itd. Tu na forum możemy sobie prognozować, co będzie z taką bazą, ale będzie to miało wartość hipotezy badawczej, którą trzeba zweryfikować pomiarami.

Niestety, nie można użyć Sfery w .NET 5. Nie będzie się dało tego zrobić, dopóki sama Sfera nie zostanie przebudowana tak, żeby targetowała .NET 5. Trudno w tej chwili powiedzieć, czy i kiedy to nastąpi, więc póki co, aplikacje sferyczne powinny być tworzone w .NET Framework.

Ten błąd nie występuje w nowej wersji biblioteki, która na razie dostępna jest w Laboratorium. W związku z tym nie będziemy go poprawiać, bo w wersji 37/38 nowa biblioteka zastąpi aktualną, więc wszyscy użytkownicy będą mieć wersję bez błędu.

NIestety nie zmieściliśmy tej poprawki do wersji 35, ale w 36 już będzie.

Do tego dążymy, ale obawiam się, że w najbliższych wersjach nie uda się tego zrealizować.

Niestety, nie planujemy wprowadzenia takiej opcji w najbliższej przyszłości. Mamy jednak tę sugestię na uwadze i uwzględnimy ją przy planowaniu kolejnych wersji.

Zbiorczy zapis załączników jest możliwy w nowej wersji modułu biblioteki załączników, którą obecnie można włączyć w Laboratorium. Planujemy ją wdrożyć u wszystkich użytkowników w wersji 36 lub 37. Nie ma tam jednak opcji eksportowania do folderu odpowiadającego dokumentowi i na razie nie mamy w planach tego dodawać. Można jednak zrealizować taki scenariusz za pomocą Sfery.

Będą mogły, tzn. będzie możliwe podpięcie tego samego załącznika do OE i ZK, ale czy zostanie zaimplementowane automatyczne ich podpinanie, to trudno mi w tej chwili powiedzieć.

Planujemy udostępnienie takiej opcji w wersji 35 lub 36.

To zależy od okoliczności. Jeśli ma Pan takie załączniki w bibliotece i włącza Pan migrację do nowej wersji, to może Pan wybrać, czy duplikaty mają być scalone do jednego załącznika czy też przeniesione do nowej biblioteki ze zmienionymi nazwami, które są generowane automatycznie. Jeśli przed migracją było 10 plików "readme.txt" o identycznej zawartości, to po migracji w pierwszym wypadku (scalenie) będzie jeden plik "readme.txt", a drugim (zmiana nazw) będzie 10 plików o nazwach "readme_000001.txt", "readme_000002.txt" i tak dalej. Jeśli pliki przed migracją miały takie same nazwy i rozszerzenia, ale różne zawartości, a wybrano opcję scalenia, to i tak nie zostaną scalone, ze względu właśnie na różnice w zawartości. W takiej sytuacji zostaną przeniesione do nowej biblioteki pod nową nazwą. Po przejściu na nową bibliotekę będzie to wyglądało tak, że przy dodawaniu nowego załącznika sprawdzamy, czy ma on unikalną nazwę i rozszerzenie. Jeśli nie jest, to program zapyta, czy powinien nadpisać istniejący załącznik czy dodać nowy załącznik pod jakąś inną nazwą. Zawartość nie jest tu brana pod uwagę, więc nie można dodać dwóch plików "fs.pdf" różniących się zawartością.

Taki błąd może mieć różne przyczyny, ale w tym wypadku najprawdopodobniej chodzi o timeout przy przesyłaniu plików nowej wersji na serwer. Może być to spowodowane np. zbyt małą ilością pamięci dostępną w danym momencie dla serwera. Czy próbowała Pani zrestartować serwer? To może pomóc, a jeśli nie pomoże (co jest możliwe, bo strzelam tu trochę w ciemno z tą diagnozą), to bardzo proszę w programie serwisowym nexo skorzystać z opcji "Pomoc" -> "Eksportuj informacje diagnostyczne", żeby wygenerować paczkę z logami programu, a potem wysłać tą paczkę do InsERTu przez formularz kontaktowy. To pozwoli nam sprawdzić, czy rzeczywiście chodzi tu o timeout.

Tak, dodaliśmy nowe tabele i kolumny. Nic nie zostało usunięte. Należy się spodziewać, że w momencie, gdy usuniemy z API stare interfejsy, to pociągnie to za sobą usunięcie odpowiadających im tabel i kolumn z bazy danych.

Aktualnie nie ma takiej możliwości, ale niewykluczone, że w przyszłości to dodamy.