Jerzy Dudra

Zrezygnowaliśmy z usuwania zdjęć z poziomu galerii zdjęć obiektu bo zdjęcie może być używane gdzieś indziej (np. w innym towarze). Tworzy to pewne ryzyko, że można "niechcący" usunąć sobie zdjęcie powiązane z innymi towarami. Obecnie jeżeli chcemy usunąć wszystkie zdjęcia towaru "na zawsze" należy: Pobrać galerię zdjęć tego towaru (IAsortyment.PobierzGalerieZdjec()) Z galerii towaru pobrać zdjęcia IGaleriaZdjecObiektu.PobierzZdjecia(); Pobrać globalną galerią Uchwyt.PodajObiektTypu<IGaleriaZdjec>() dla każdego zdjęcia do usunięcia wykonać: IGaleriaZdjec.UsunZdjecie(..) A pisząc po ludzku np. jakoś tak: IGaleriaZdjec galeriaZdjec = uchwyt.PodajObiektTypu<IGaleriaZdjec>(); IAsortyment towar = PodajTowarZeZdjeciamiDoWywalenia(); var galeriaZdjecTowaru = towar.PobierzGalerieZdjec(); foreach (var zdjecieDoUsuniecia in galeriaZdjecTowaru.PobierzZdjecia()) { galeriaZdjec.UsunZdjecie(zdjecieDoUsuniecia); }

Opis z "Inner Exception" może wskazywać na to, że problematyczny plik DLL (tutaj ThemeControls.dll) ma ustawiony atrybut "Zablokowany". Proszę sprawdzić, czy ThemeControls.dll (i prawdopodobnie inne pliki) nie jest zablokowany. Widać do we właściwościach pliku na pierwszej zakładce, poniżej klawisza Zaawansowane. Można to znaleźć w tym miejscu: Windows blokuje czasem pliki skopiowane z lokalizacji sieciowych w ten sposób, ze względów bezpieczeństwa.

Tak przypuszczałem (że chodzi o wersję rozwiązania). Z poziomu rozwiązania własnego nie da się tego wyciągnąć. Zanotowaliśmy sugestię, żeby to udostępnić

Trochę nie rozumiem pytania Chodzi o wersję nexo, czy wersję rozwiązania własnego ? PS. Wersję nexo w rozwiązaniu własnym można odczytać przez DanePolaczenia.WersjaSfery

Problem wynika z tego, że Aplikacja WPF nie ma jawnej referencji do pliku InsERT.Moria.ThemeControls.dll (i jeszcze paru innych). Dlatego podczas kompilacji Pana programu nie ma go w folderze z Pana prograem. Doraźnie można ten problem rozwiązać np. poprzez skopiowanie z SDK brakujących plików do folderu z programem. Lepszym rozwiązaniem będzie jednak posłużenie się szablonem do tworzenia aplikacji wpf, dostarczonym w SDK. Szablony projektów są opisane w dokumentacji w rozdziale 'Szablony projektów dla Visual Studio'

W tej chwili raporty sferyczne nie mają takich parametrów. Zanotowałem sugestię. PS. Gdyby powtórzył Pan występujący u Pana błąd (błąd kompilacji), to czy Mógłby Pan podesłać (na priv) plik z logiem ze stanowiska na którym wystąpił. Chodzi mi o plik logu znajdujący się zwykle w takiej lokalizacji: c:\Users\{użytkownik windows}\AppData\Local\Insert\Logs\NexoLog.txt

Jest błąd po naszej stronie z pewnymi znakami w opisie opcji parametru listowego. Prawdopodobnie użył Pan w opisie opcji tekstu, który zawiera znak " (cudzysłów) lub # (hasz). Zapewne towar ma w nazwie któryś z problematycznych (obecnie) znaków.

Parametr ten nie był projektowany do takiej liczby elementów. Sprawdza się przy liczbie elementów mieszczących się na ekranie (lub trochę więcej).. Czy mógłby Pan napisać ile było elementów na liście? Czy mógłby Pan pokazać fragment kodu generującego parametr powodujący błąd?

Proszę jeszcze pokazać na zrzucie ekranu plik InsERT.Moria.Sfera.dll z katalogu SDK, tak żeby była widoczna data jego utworzenia i rozmiar. Dobrze by było, gdyby mógł Pan pokazać maksymalnie obszerną zawartość katalogu bin SDK'a

To może od końca: nexoSDKSzablony_VS2019 i nexoSDKSzablony_VS2022 to pakiety do Visual Studio z szablonami projektów dla rozwiązań sferycznych. PackageAndInstalledBuilder.exe i QuickInstallerBuild.exe to elementy wykorzystywane w projektach tworzonych z szablonów z pakietów. Jeżeli chodzi o program sferyczny to komunikat taki zwykle wskazuje na rozbieżność między InsERT.Moria.ModelDanych.dll i bazą danych. Upewniłbym się czy na pewno Pana rozwiązanie było kompilowane z SDK zgodnym z bazą danych. Dla wersji 41.0.1 właściwy SDK to NexoSDK_41.0.1.5571.exe. Pisał Pan, że zaktualizowano bazę do wersji 41.0.1, Zakładam więc, że NEXO w wersji 41.0.1 działa na tym stanowisku. Folder, o którym Pan pisze: C:\Users\admin\AppData\Local\InsERT\Deployments\Nexo\Exxxxxxxx2266f8c2095e943b5a608c2\Binaries\ to folder podmiotu, z którym działa Subiekt NEXO w wersji 41.0.1. Jeżeli tak, to proszę sprawdzić czy plik InsERT.Moria.ModelDanych.dll jest taki sam w folderze C:\Users\admin\AppData\Local\InsERT\Deployments\Nexo\Exxxxxxxx2266f8c2095e943b5a608c2 w SDK (w lokalizacji \nexoSDK_41.0.1.5571\Bin w folderze do którego buduje Pan swoje rozwiązanie.

Zwykle taki błąd ('Podana baza danych nie jest .. ') wynika z rozbieżności wersji bazy danych i 'binariów'. Może to być sytuacja, gdy baza jest zaktualizowana do wersji 41.0.1, a 'binaria' których używa rozwiązanie sferyczne są z wersji wcześniejszej. Czy rozwiązanie własne działa na stanowisku, na którym pracuje Subiekt NEXO, jeżeli tak to czy Subiekt się uruchamia? Jak dokładnie wygląda ta referencja?

W najbliższym czasie, nie planujemy dynamicznego generowania kolumn na podstawie wyniku zapytania.

Na 99% z wersją 4.7.2 powinno działać (biblioteki NEXO mają ustawienie 4.6.1) Brak numerów linii w StartTrace w wyjątku wynika zwykle z problemu z plikami PDB w aplikacji, która "rzuca" wyjątkiem. Być może nie wynika on z ustawienia 'Target framework '.

NEXO obecnie używa nowszej wersji Newtonsoft.Josn'a app.config Subiekta dla Newtonsoft.Json ma obecnie takie przekierowanie: <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentAssembly> <assemblyIdentity name="Newtonsoft.Json" culture="neutral" publicKeyToken="30ad4fe6b2a6aeed" /> <bindingRedirect oldVersion="0.0.0.0-13.0.0.0" newVersion="13.0.0.0" /> </dependentAssembly> </assemblyBinding>

Czy mógłby Pan przysłać dane diagnostyczne NEXO z tych dwóch stanowisk?

Jeżeli zainstalowano NEXO na tej maszynie to wymagania software'owe są spełnione. Czy z bazy na tym serwerze korzystają inne stanowiska. Jeżeli tak, to działają one 'lepiej'? Czy 'wolniejsze działanie' widać przy każdym uruchomieniu czy tylko przy pierwszym? Czy NEXO działa na tej maszynie wolniej? Czy rozwiązanie sferyczne jest wdrożone 'pakietem wdrożeniowym' czy inaczej?

Proszę skopiować z SDK do katalogu z rozwiązaniem plik xml.pak. Czy Pana program korzysta z interfejsu użytkownika nexo (użyto konstrukcji mp.DostepDoUI = true, gdzie mp to MenedzerPolaczen) ?

Można zamiast nazwy użytkownika wskazać identyfikator użytkownika. Należy wtedy użyć metody z identyfikatorem (Guid) a nie loginem. Listę loginów identyfikatorów i opisów można odczytać np. takim sql'em: SELECT Id,Login,Nazwa FROM ModelDanychContainer.Uzytkownicy

Ten komunikat pojawia się gdy podamy nieprawidłowe hasło lub wskażemy nieprawidłowy login użytkownika. Logując się do programu (Subiekt,Rachmistrz,Rewizor..itp) na liście użytkowników do wyboru pojawiają się opisy użytkowników. Podczas logowania do sfery należy wskazać login. Może to być trochę mylące. Czy na pewno logując się sferycznie wskazano login?

A co zwraca metoda Zaloguj? public SferaWynikLogowania Zaloguj(Guid id, string haslo) (jest "obok" metody ZalogujOperatora)

W sprawie identyfikatorów typu tekstowego w {CHL:} zapisuję sugestię. Jeżeli chodzi o kolejność klucz,nazwa to tego na pewno nie dotkniemy

Teoretycznie można użyć wariantu parametru {CHL..} z jawnym wskazaniem dostępnych typów ({CHL:Typ dok:ZK#1#FS#2}). Jeżeli lista typów jest długa lub często występuje w definicji, definicja raportu robi się zagmatwana. Lista wartości dla 'Typ elementu' nie jest dostępna z poziomu bazy danych.

Problem tkwi w tym, że zapytanie z definicji parametru CHL (fragment definicji {CHL:Typ:<zapytanie sql>}) jest wykonywane niezależnie od 'głównego zapytania'. W praktyce oznacza to, że nie ma w nim <zapytanie sql> dostępu do zmiennych, tabel tymczasowych zdefiniowanych z 'głównym zapytaniu' Działające obejście, jakie mogę zaproponować, to użycie zwykłej tabeli SQL(CREATE TABLE _typyDoumentow ... ) dla listy typów dokumentów.

Zapisaliśmy taką sugestię. PS. Fajna sugestia, na teraz nie jestem w stanie wskazać, w której wersji będzie to dostępne.

Raport LINQ przewiduje tylko jedno repozytorium źródłowe. Nie da się w definicji raportu użyć dwóch różnych repozytoriów wejściowych.