Temat: Cechy referencyjne
Tak poleciłbym swoje rozwiązanie. Oczywiście wyjaśnię czemu, bo zaraz będą wszyscy oburzeni na forum.
Mówisz o gmeraniu w bazie, jak wspominałem jest kilka sposobów na założenie takiej cechy. Są też rozwiązania bez ingerencji w SQL-a. Cecha się kompiluje poprawnie. Da się ją replikować do dowolnej bazy w dowolnej wersji. Import definicji z pliku XML przebiega poprawnie bez błędów, czyli jest ona poprawna? Całym problemem jest ograniczony GetList, który nie wyświetla nam PozycjeDokHan. Oczywiście moja cecha w polu tabela referencyjna pokazuję już tą wartość. Bym nie był gołosłowny, taką cechę założyłem na wersji 10.0.0 z listopada 2013 i uzupełniłem kilka cech. Następnie bazę podałem szeregu konwersji, aż do wersji 11.3.2 z końca marca 2016. Czyli jak widać przez prawie 3 lata cecha by działała. Dodatkowo by utrudnić warunki po drodze baza była konwertowana przy użyciu własnego modułu napisanego za pomocą BusinessGenerator-a. Cechy są rzeczą fundamentalną w enova i ich zmiana w tym kierunku, że moja cecha przestanie działać jest mało prawdopodobne. Szybciej spodziewane jest umożliwienie w standardzie definiowania takich cech.
Same zalecenie producenta mówią o tym by wszystko co się da robić za pomocą standardowych elementów, które są zapisywane w bazie np. taski, cechy. Wtedy całą konfiguracje mamy w jednym miejscu i replikacja bazy to tylko jej odtworzenie i oczywiście łatwiej o debugowanie problemu. Oszczędzamy również czas na rzeczy związane z obsługą dllek. Łatwiej jest wtedy także o pomoc producenta, czyli Sonety.
Natomiast drugie rozwiązanie z "dodatkowym polem" wymusza napisanie extendera do obsługi, czyli dllki. Jak jest z dllkami to każdy wie. Pamiętamy brak możliwości dllelek na Azure(nie wiem jak jest obecnie). Problemy z formsami to jest temat rzeka. Jeśli nie przepisałeś dllek to nie działa Ci SonetaServer zatem HZ i pulpity oraz wersja multi. Chyba, że masz inny zestaw dll pobierany przez SonetaServer. Jeśli miałeś taska to zaznaczasz tylko opcję "Uruchamiaj w Soneta Explorer" i po problemie. Coś co jest w środku bazy i korzysta z standardowych funkcji Soneta prawie zawsze będzie działać lepiej niż coś napisane na boku. Problem przy licencjach wielofirmowych, gdzie użytkownik ma 5 różnych firm/baz i każda firma ma inną konfigurację. Ja importuję tylko cechę do odpowiedniej bazy i po problemie, a z dllką? Trzeba pisać n skrótów do programu z parametrami. Pamiętamy także własne moduły i brak ostrzeżeń przy konwersji co przez nieodpowiedzialnych pracowników skutkowało utratą danych z naszej tabeli!!! Każdy też spotkał się z sytuacją, że Windows lub program antywirusowy zablokował nam dll. Trzeba przy rozbudowanej konfiguracji HZ, SonetaServer + baza pamiętać o podgrywaniu dllki w różne miejsca. Wiadomo nasze dllki od czasu do czasu trzeba przekompilować. Kolejny problem to trzeba nadpisywać standardowe pageformy i gridy by to pole się pokazało, często zmieniając XML-a. Mając cechę sam zwykły użytkownik może w dowolnej formie(standard,multi) enova spokojnie wyciągnąć sobie cechę. Nie muszę również wspominać, że łatwiej jest skorzystać z cechy na raporcie niż z extendera. Łatwiej również o zmianę definicji cechy na żywo. Użytkownicy tylko odświeżają opcję, maksymalnie się przelogowują. Z dllką trzeba ponownie uruchomić program/SonetaServer. Czas rozwiązania drugiego to ok. 2 - 3 godz? Moje rozwiązanie to 15 min.
Podsumowując, by nie ciągnąć tego tematu w nieskończoność. Ja jestem pewny swego rozwiązania i wdrożyłbym to na bazie produkcyjnej. Oczywiście mamy demokrację i każdy z Was może taką sytuację ocenić inaczej. Każdy wykonawca ocenia samemu ryzyko danego rozwiązania. Musielibyśmy postawić dwie bazy jedną z moim rozwiązania, a drugą z Twoim i poczekać parę lat i zobaczyć, które rozwiązanie było lepsze. Jednak to jest niemożliwe.
--
Serdecznie pozdrawiam / Best Regards
Rafał Tujek
Programista systemów ERP
mail:rafaltujek@gmail.com
tel.:795-924-911
пропозиції роботи
