_euan_

Czy istnieje mozliwosc uruchomienia Sello z argumentami w cmdline? Dokladniej chodzi mi o cos takiego, że np mamy dwie bazy sello, a tylko jeden plik sello.xml w ktorym mozemy ustawic baze i usera, zeby wlaczal sie bez wybierania na starcie. Wiec pytanie czy moznaby odpalic sello podajac mu jako argumenty baze danych i usera z tej bazy np: sello.exe -u Szef -p haslo -s serwer -db moja_baza Czy istnieje taka mozliwosc?

Jak programista jestem jak najbardziej za, ale wiem ze przyjdzie na to poczekac conajmniej rok.

Witam. Rowniez prosilbym o niezbedne pliki i instrukcje co i jak do obslugi Siodemki w Sello. eurokom2@o2.pl Z gory dzieki.

No i ładnie. Juz znaczek wodny z allegro działa jak nalezy :] Ale mimo to wprowadzenie w sello bardziej rozbudowanego byloby super.

Witam. Niedawno zauważyłem na allegro opcję znak wodny. W ustawieniach konta, na zakladce Szablony, mozna ustawić znak wodny o tresci swojego nicku allegro, kolor, przezroczystosc oraz pozycję na zdjęciach. Można indywidualnie przy wystawianiu aukcji przez stronę zaznaczać tą opcję czy ma być wygenerowany znak czy nie. W ustawieniach jest opcja "Domyślnie znakuj zdjęcia podczas wystawiania przedmiotu.". Po jej zaznaczeniu każde dodane przez nas fotki sa opatrzone znakiem wodnym. Co z obsługa tej nowej funkcjonalności przez Sello? Pierwsze co oczywiscie zrobilem, to ustawilem na domyślne znakowanie wszystkich zdjęć przy wystawianiu i wystawilem aukcje testową z Sello. Niestety, wbrew moim oczekiwaniom, serwis allegro nie przepuszcza przez tą procedurkę zdjęć dodanych poprzez ich API i dodanie znaku nie nastepuje. Może wrzucicie jakiś mały update? Wkoncu to tylko poszerzenie klasy o jedno pole typu bool. No ale tez kwestia czy API allegro tez juz to obsluguje. Ogólnie to swietna sprawa z tym dodawaniem znaków w locie. Można to zaimplementować w Sello (nie zeby dodawał znak na stałe do zdjecia w swojej bazie, tylko zeby nakladal znak przed samym wsyalniem zdjec do serwa), badz dorzucic obsluge tej funkcji z Allegro. Moim zdaniem byłoby lepiej zrobic to w sello - wieksze mozliwosci konfiguracji znaku wodnego (tekst, rozmiar, dokladniejsze polozenie), bo w allegro wymuszony jest nick jako tekst i rozmiar tez niekonfigurowalny.

Sello po dluzszym czasie pracy moze sie nieco rozszerzyć to fakt. Jednak u mnie dzieki automatycznym restartom na serwie nie wychodzi powyzej 60 mb

Automatyczny backup baz danych Sello i Subiek GT Backup oparty w 100% o darmowe rozwiązanie. Jakoże bazy Sello i Subiekta (przynajmiej w firmie w której pracuje) nie zajmują zbyt dużo (po spakowaniu Subiekt 40mb, Sello 113 mb - ale szybko rośnie), dlatego można pokusić się o robienie kopii pełnych zamiast przyrostowych. Osobiscie jestem zwolennikiem robienia pełnych backupów - takie zboczenie zawodowe. Sytuacja: jest serwer o nazwie SERWER na którym uruchamiany jest MSSQL server i chcemy aby automatycznie robił sobie backup, np. subiekta raz dziennie, a sello dwa razy dziennie. Żeby nie było zbyt rozrzutnie dorzucimy do tego automatyczne archiwizowanie backupów rarem i okresowe usuwanie kopii przestarzałych. Backupy bedziemy przykładowo przechowywać na zewnetrznym dysku E:\_backup\Sello\spakowane i E:\_backup\SubiektGT\spakowane. 1. Pobieramy darmowy programik SQL Scheduler http://www.lazycoding.com/downloads/SQLScheduler_LatestVersion.zip 2. Dodajemy nowy serwer na liście, w naszym przypadku będzie to SERWER\INSERTGT (jakoze domyslnie tam są bazy GT i Sello) 3. Klikamy prawym SERWER\INSERTGT i wybieramy New Job: GENERAL: Connection SQL Server Authentication Username: sa Password: DETAILS: SQL: -------------------------------------------------------------------- DECLARE @BackupName VARCHAR(100) DECLARE @BackupFileName VARCHAR(100) DECLARE @BackupPath VARCHAR(1000) SET @BackupName = 'nazwa_bazy-' + convert(nvarchar(20), getdate(), 112) SET @BackupFileName = @BackupName + N'.bak' SET @BackupPath = N'E:\_backup\Sello\' + @BackupFileName BACKUP DATABASE nazwa_bazy TO DISK = @BackupPath WITH NOFORMAT, NOINIT, NAME = @BackupFileName, SKIP, REWIND, NOUNLOAD, STATS = 10 exec xp_cmdshell 'C:\WINDOWS\sello.bat' ---------------------------------------------------------------------- Script timeout in seconds: 1200 SCHEDULE: Type Recurring every 12 hour Duration 16:30 4. Klikamy save. To zadanie bedzie wykonywało backup bazy Sello o nazwie nazwa_bazy o godzinie 16:30 i 4:30. Na koniec wykonywania backupu uruchamiany jest plik sello.bat, który musimy stworzyć i wrzucić, w tym przypadku, do C:\WINDOWS. sello.bat: cd E:\_backup\Sello E: "C:\Program Files\WinRAR\rar.exe" a -df -rr1 -ag[DD-MM-YYYY-HHmm] -ri7 %1 E:\_backup\Sello\spakowane\sello-%1.rar 5. Wykonanie powyzszego skryptu spowoduje spakowanie RARem wszystkich plików znajdujacych się w katalogu E:\_backup\Sello i umieszczenie archiwów w podkatalogu 'spakowane' o nazwach w formacie 'sello-[17-09-2008-1630].rar'. Czyli w nawiasie data i godzina wykonania backupu. Dodatkowo niespakowane kopie zostaną usuniete z nadrzędnego katalogu. 6. Dla Subiekta GT sytuacja wygląda praktycznie identycznie, wystarczy zmienić ścieżki i nazwy baz. SQL bedzie wyglądał np tak: DECLARE @BackupName VARCHAR(100) DECLARE @BackupFileName VARCHAR(100) DECLARE @BackupPath VARCHAR(1000) SET @BackupName = 'nazwa_bazy-' + convert(nvarchar(20), getdate(), 112) SET @BackupFileName = @BackupName + N'.bak' SET @BackupPath = N'E:\_backup\SubiektGT\' + @BackupFileName BACKUP DATABASE nazwa_bazy TO DISK = @BackupPath WITH NOFORMAT, NOINIT, NAME = @BackupFileName, SKIP, REWIND, NOUNLOAD, STATS = 10 exec xp_cmdshell 'C:\WINDOWS\subiektgt.bat' subiektgt.bat: cd E:\_backup\SubiektGT e: "C:\Program Files\WinRAR\rar.exe" a -df -rr1 -ag[DD-MM-YYYY-HHmm] -ri7 %1 E:\_backup\SubiektGT\spakowane\subiekt-%1.rar 7. Mając w SQL Scheduler uruchomione dwa powyższe zadania, ustawione na godziny jakie nam odpowiadają, możemy być spokojni o ewentualną awarię bazy danych, gdyż możemy ją w każdej chwili przywrócić. Ścieżką docelową kopii zapasowych powinien być najlepiej dysk zewnętrzny, który w wypadku awarii sprzętowej serwera lub jego dysku, pozostanie nienaruszony. Przechowywanie backupów na tym samym dysku na którym znajduje się zainstalowany MSSQL jest pozbawione sensu, gdyz w wypadku awarii sprzętowej pozostajemy z niczym. Jako ścieżkę docelową możemy również użyć sieciowej lokacji, jednak powinna ona być dostępna cały czas. Na tą chwilę poprzestańmy na tym, że serwer uzywa jedynie wewnetrznego dysku oznaczonego literą C:\, a dysk E:\ to jakis zewnetrzny dysk na USB lub w najgorszym wypadku pendrive. Nastepnym razem dopisze jak zautomatyzowac zarządzanie backupami, czyli ich usuwanie gdy są starsze niż podany przez nas okres czasu, aby nie doprowadzić do zapełnienia dysku.

no własnie niezbyt dbacie o klienta Subiekta. sello ma swietny support. a z subiektem to sie insert na ludzi wypina. myslalem ze moze jestes zaangazowany jakos posrednio w projekt subiekta. to pomecze pomoc techniczna jednak.

wychodze z założenia że z tej opcji korzystają ci ktorzy mają odpalone sello ciągle na serwerze, jak np. ja. ogolnie uzywanie sello w sposob taki zeby odpalac tylko w czasie pracy jest dla mnie nieco nielogiczny, niewygodny. wiele opcji nie ma wówczas zastosowania i automatyzacja, która jakby nie patrzec jest jednym z głównych zastosowan sello, jest niewykorzystywana.

domyslam sie ze latwo sie w tym pogubic. jak pisalem kiedys prace inzynierska z inzynierii oprogramowania to zaledwie 6 tys. linijek kodu przyspozylo mi kilku problemow, rowniez z wyciekami pamieci z zupelnie innej beczki: jesli praacujecie nad subiektem, to mam pytanko - czy planujecie wprowadzić do mobilnego subiekta mozliwosc sciagania towaru przy pomocy czytnika kodów kreskowych? chodzi mi dokladniej o cos takiego: jest sobie koles z PPC, mobilnymSubiektem i podlaczonym przez złacze karty SD recznym czytnikiem kodów paskowych. Odpala sobie np. tworzenie fakturki sprzedazy i zamiast dodawac towar recznie z listy, poprostu śmiga czytnikiem po kodach kreskowych na towarze, a subiekt wrzuca je na fakturke (czy tam WZ, czy paragon, jakikolwiek dokument). byłaby to BARDZO przydatna funkcjonalność dla przedstawicieli handlowych, która znacznie by przyspieszyła obsługe klienta - mobilny subiekt jest niewygodny, jak kazda aplikacja na PPC - utworzenie faktury sprzedazy np 20 różnych produktów zajełoby wielokrotnie wiecej czasu niż piknięcie czytnikiem 20 razy w kody paskowe towarów. pytam się tutaj bo subiekt gt nie forum a obsługa techniczna jest płatna - a wkoncu zapytac o mozliwosc funkcjonalnosci to mozna raczej za darmo

Przepraszam jesli taki watek był, ale nie znalazłem. Dopiero dzisiaj zainteresowałem się planowym rozpoczynaniem aukcji. Byłem wręcz przekonany że działa to tak: zaznaczam grupe aukcji, wybieram z menu Ustaw datę wystawienia, wpisuje co trzeba. sello sobie działa i gdy nadchodzi ustawiona data/godzina, zmienia status aukcji na Gotowa do wystawienia i wywołuje procedure wysyłania danych do serwisu aukcyjnego. w ten sposob o danej godzinie danego dnia aukcje zostaną wystawione - czyli super. moznaby sobie tak poukladac w wolnym czasie harmonogram na pol roku i sie tym nie przejmowac. Jakie było moje zdziwienie gdy uswiadomilem sobie ze aukcje są wysyłane na serwer odrazu i wystawiane planowo przez allegro - oczywiscie za opłatą. Na 100% każdy z użytkowników wolałby żeby Sello planowo wystawiało samo aukcje nie pobierając za to opłaty przecierz, niż 5 gr od aukcji dla allegro za to że leżą one na serwerze i czekają na odpalenie. Moim zdaniem to funkcjonalność która musi koniecznie być w Sello.

pomyslalem sobie ze warto bedzie zalozyc nowy topic jak wykonac zautomatyzowany i darmowy backup bazy sello i subiekta, wiec tam zobaczysz dokladniej jak to przebiega. w zasadzie to pomyslalem sobie teraz ze problem zapetlania sello wystepowal zanim zrobilem te backupy, jednak byla to wowczas wersja 1.1.2 no ale moze cos z tego wymyslisz.

oj niechlujnie panowie programisci. destruktorów sie pisac nie chciało? :>

jak narazie nie poradzilem sobie w zaden konwencjonalny sposob z problemem zapetlajacego sie sello. czesto zdazalo sie ze zostawala sama ikonka w trayu, a aplikacja byla poprostu wylaczona (tez nie wiadomo z jakiego powodu). jedyne rozwiazanie jakie przyszlo mi do glowy to zautomatyzowane restarty sello np. 2 razy w ciagu dnia zeby dzialalo po 12 godzin jako "swieze". ja uzywam rozwiazania darmowego, prostego i skutecznego, moze sie komus przyda: 1. Pobieramy darmową wersje System Scheduler'a http://www.splinterware.com/download/ssfree.exe - zaplanowane zadania (harmonogram) w win xp to ogromna porazka. Instalujemy go oczywiście. 2. Pobieramy darmowy, bardzo uzyteczny programik NirCmd http://www.nirsoft.net/utils/nircmd.zip 3. Po rozpakowaniu NirCmd, wrzucamy plik nircmdc.exe do katalogu C:\WINDOWS 4. Ten krok jest elastyczny - można go zrobic na kilka sposobów. Jeden z nich to utworzyć plik typu BAT (np. selloclose.bat). Wrzucamy np. do C:\WINDOWS i edytujemy: nircmd.exe closeprocess sello.exe 5. Odpalamy System Schedulera. Wybieramy Action->New event. Title: Zamykanie Sello Event Type: Run Application Application: C:\WINDOWS\selloclose.bat State: Normal Schedule type: Every hour/Selected minutes user choosen hours -> 4,16,23 user chooden minutes -> 15 Nastepny event: Title: Uruchamianie Sello Event Type: Run Application Application: C:\Program Files\InsERT\Sello\Sello.exe State: Minimized Schedule type: Every hour/Selected minutes user choosen hours -> 4,16,23 user chooden minutes -> 45 6. Oba eventy oznaczamy jako enabled i po sprawie. Sello bedzie się wyłączało 3 razy dziennie na 30 minut, po czym będzie włączane ponownie. W moim przypadku jest to przerwa 30 minutowa i 3 razy dziennie akurat o tych godzinach a nie innych, gdyż w tym czasie wykonywane są automatyczne backupy różnych baz MSSQL (Sello, Subiekt GT i inne) oraz pare innych rutynowych czynności (przez ktore całkiem mozliwe ze Sello sie zapetlało - nie wiadomo). Jak pisalem wczesniej - rozwiazanie prostackie, ale skuteczne.

Masz racje Bartek. Tez uważam że przyczyną są czynniki zewnętrzne. Jednak możnaby wprowadzić procedury sprawdzające w czasie synchronizacji. Sello jednak powinno być przygotowane i wiedzieć co zrobić gdy np. nie mozna nawiazac połączenia z serwerem pocztowym, czy jeśli wogóle nie dostaje odpowiedzi od serwera DNS gdy net jest rozłączony z jakiejs przyczyny (co sie czasami zdarza). Wprowadzić jakis dodatkowy error handle i w wypadku niemożliwosci wykonania operacji zaprzestać danej synchornizacji i czekać najnormalniej w świecie na kolejną. Jeszcze prościej możnaby to rozwiązać wprowadzając najzwyklejszy timeout danej operacji. Dodatkowo do raportu przydałoby się dodać jakieś dodatkowe informacje z jakiego powodu wystąpiły błędy w synchronizacji. Przy jakim poleceniu itp. Łatwiej bedzie to debugować i dla usera tez bedzie to bardzo pomocne. Jednym słowem nie zadbałeś dostatecznie o obsługe błedów pisząc ten moduł

Proponuje nie instalowac wogole SP3. SP2 + kilka łatek jest całkowicie bezpieczny i stabilny. SP3 powoduje jedynie problemy. Lepiej recznie instalować odpowiednie łatki niż 240 w jednym paku z czego istotne jest raptem 10. PS. mowie o wersji XP Pro

Sytuacja taka sama jak w poprzednich wersjach: Jest serwer, który uruchamia MSSQL dla subiekta i sello. Jakoze włączony jest 24h/dobe odpalony jest na nim również klient Sello, który pełni funkcję automatycznego synchronizatora (odbieranie transakcji i komentarzy, tworzenie nowych wiadomości do transakcji, wysyłanie automatycznych wiadomości). Serwisy aukcyjne: tylko odbieraj - 10 minut Strefa Sello: nie synch. Wiadomości: wysyłaj i odbieraj - 3 minuty Subiekt GT: nie synch. Użytkownik upowazniony do synchronizacji automatycznej: serwer Klient sello odpalony na serwerze jest oczywiscie zalogowany jako uzytkownik "serwer". Nikt wiecej nie loguje sie na to konto. Problem i zachowanie: Sello "serwer" uruchomiony o godzinie 10 rano. Synchronizuje wszsytko ładnie. O 16 koniec pracy, reszta klientow sello jest wyłączana, pozostaje tylko "serwer" na serwerze :]. Odpalam o 10 rano nastepnego dnia sello na moim kompie i dopiero moje sello wysyła wiadomosci o nowych transakcjach do uzytkownikow. Sprawdzam wiadomości/wysłane i okazuje sie ze serwer wysyłał wiadomosci o nowych transakcjach np. do godziny 20:13. Czyli przypuszczam że mniej wiecej po tym czasie musiało nastapic zapętlenie. Wchodze na serwer, maksymalizuje sello i widze ze na pasku stanu sello przeskakują informacje typu Obieranie wiadomosci/ Wysylanie wiadomosci/ Pobieranie transakcji itp. Zmieniaja sie w szybkim tempie (ktore w tej wersji mozna ustawic w opcjach). Nie widnieje obok krzyzyk ktorym sie zatrzymuje trwajaca operacje - wskazuje to na to ze sello poprostu nie wykonuje nic w tym czasie. Zapetlilo sie w wyswietlaniu tych napisow i zapomialo o automatycznej synchronizacji. Sytuacja zdaza sie przynajmniej 4 razy w tygodniu. Nie mam pojecia co ją wywołuje. Czasami potrafi działać jak nalezy przez 4 dni, czasami raptem pare godzin. Od dzisiaj zaczne dochdzenie w tej sprawie - bede przed wyjsciem z pracy restartowal sello o 16 na serwerze i obserwował jak sobie radzi przez obserwacje raportu oraz godzin wysylek utowrzonych automatycznie wiadomosci. Jakies przypuszczenia co to moze byc? Spotkal sie ktos z takim problemem? Jest to dość istotne, bo jak klient kupi sobie towar np o 1 w nocy, to dostaje maksymalnie po 10 minutach maila z wszystkimi danymi, instrukcjami do dokonczenia zakupów itp. i moze to od reki zrobic. W momencie gdy serwer sie zapetli, klienci zasypuja mailami z prosbami o konto, lub ile trzeba zaplacic itp. itd. i dopiero o 10 rano wysyłam im te wiadomosci gdy odpale swoje sello (jeszcze gorzej sytuacja wyglada w weekend - jesli serwer sie zapetli w piatek wieczorem to wiadomosci klienci dostana dopiero o 10 w poniedzialek, jako ze w week nie pracujemy).

Czemu nie odpalić nowego wątku z niższmym priorytetem który odpowiedzialny byłby za zgrupowanie transakcji lub wysyłanie/odebranie paczek? wielowątkowość to jednak podstawa. operacje iteracyjne najlepiej umieszczać w osobnych wątkach nie w głównym, żeby właśnie uniknąć owego zamrażania aplikacji. można na to oczywiscie wpłynąć poprzez priorytetowanie wątków. rozumiem że pozostawiliście to w głównym wątku gdyz nie jest to operacja długa ani skomplikowana - więc skończy się błyskawicznie nie powodujac przyhamowania sello. owszem macie racje - ale wychodzi na to że "algorytm" grupowania macie naprawde spieprzony, jeśli powoduje takie zamrażanie dla jedynie 50-120 transakcji. Nawet jesli nie ma transakcji do zgrupowania. Albo odpalic operacje w osobnym wątku albo zmienić sposob grupowania (zmienic zasadę porównywania pól, posiedziec przy komendach wysyłanych do mssql itp.) co do wysyłane/odebrane - zdarza się coś takie przy również śmiesznie małej ilości rzędu 10-35 paczek. powiązanie z subiektem GT istnieje. wystawianie dokumentów poczatkowych czy koncowych zostało wyłączone już dawno temu. stan towarów w subiekcie również nie jest aktualizowany. połączenie z subiektem jest tylko do synchronizacji towarów (cen, zdjęć, opisów, ilości). synchronizacja z subiektem odbywa się automatycznie co 8 godzin (poza godzinami pracy). pondato automatyczne odbieranie transakcji i komentarzy ustawione jest na 5 minut (na serwerze). wysylanie wiadomosci co 2 minuty. PS. jako ze jestem programistą doskonale zdaję sobie sprawe że ważniejsze jest dla Was że aplikacja robi 100 innych rzeczy prawidłowo. że wogóle działa. tez byłoby to dla mnie najistotniejsze. no ale testy to testy dlatego zameczam takimi "bzdetami" zamrazająca sie aplikacja przy jakiejs operacji to bez wątpienia niechlujna szkoła programowania - zmiencie to, a wyjdzie Wam na dobre :] (z Subiektem GT to samo ). pozdrawiam.

Można poprosić o jakiś changelog w porownaniu do wersji 1.1.2?

Nie moze wystawic komentarza do nieistniejącej transakcji. Musiala zostac przez przypadek usunieta. Najlepiej usunac ten komentarz.

W poprzednich wersjach sello takie zachowanie również wystepowało. Myślałem ze w 1.2 zoptymalizujecie nieco kod i wspoldzielenie czasu procesora miedzy wątkami - niestety zaraz po instalacji nowej wersji sello udało mi się zrobić to co zawsze. Wystarczy włączyć Odbieranie parametrów z serwisu z zaznaczonymi wszystkimi opcjami dotyczącymi aukcji oprócz ostatniej, czyli tylko dla niekompletnych aukcji. Czekamy chwilę aż nawiąże połączenie i rozpocznie pobierać dane. Zaznaczamy wsystkie transakcje CTRL+A i grupujemy je według klienta CTRL+G. W 75% przypadków Sello zamraża się i przestaje odpowiadać. Obciążenie procesora skacze nagle ze standardowego 5-15% do 100%. Można czekać kilkadziesiat minut i nic. Należy zrestartować Sello gdyż z tego stanu najczęsciej juz nie wychodzi. Przy duzej ilosci stworzonych paczek, zaznaczamy wszystkich klientów i wybieramy Oznacz jako wyslane/odebrane. W momencie gdy Sello tworzy automatyczne wiadomosci o nadaniu wysylki następuje zamrozenie (jakies 40% szans ). Jednak z tego stanu Sello wychodzi zawsze - po uplywie nie wiecej niz 5 minut. Czy u innych występuje też takie zachowanie? Komputer na ktorym uruchamiam klienta Sello to Celeron 2,2 GHz z 2 GB Ramu. Zoptymalizowany do pracy jak należy. Na serwerze gdzie uruchamiana jest baza danych, Dell Pentium 4 3,2 GHz z 4 GB Ramu, również takie zachowanie sie pojawia. Czy programisci moga sie udzielic w tym wątku? Moze wspolnie dojdziemy do jakiegos rozwiazania, ktore spowoduje stabilniejsza prace Sello. PS. czesto tez przy pobieraniu informacji z serwera przestaje dzialac menu kontekstowe wywoływane spod prawego przycisku myszy. w poprzednich wersjach tez to bylo.

Jakby nie bylo tego pliku tam gdzie pisałem to pewnie bedzie w katalogu nie All users, tylko TWOJA_NAZWA_USERA i dalej tak samo. C:\Documents and Settings\TWOJA_NAZWA_USERA\Dane aplikacji\InsERT\Sello\sello.xml Pozatym jakis tam folder po drodze jest ukryty, chyba dane aplikacji, wiec trzeba go najpierw ujawnic. Ten plik MUSI tam byc.

U mnie przy 2500 transakcji jest tez cienko Dlatego w takim wypadku zdecydowanie lepszym rozwiazaniem jest zdalny pulpit - a w tej kwestii najlepszy z najlepszych jest Radmin.

Przypuszczam ze napotaksz przynajmniej dwa problemy po drodze. Bez VPN sie nie obejdzie. Proponuję następujące - najprostsze i w pełni darmowe rozwiązanie: 1. Ściagamy przecudny programik stad: https://secure.logmein.com/products/hamachi/vpn.asp?lang=pl 2. Instalujemy na kompach które mają być we własnej sieci wirtualnej. Wybieramy wersję darmową, czyli Basic w czsie instalacji. Tworzymy własną sieć w Hamachi (czyli tym programie). Podlaczamy sie do tej sieci - serwer i klienci. Wyłączamy firewalla na każdym komputerze podlaczonym do sieci Hamachi TYLKO na interfejsie Hamachi (czyli nowo utworzonej wirtualnej karcie sieciowej) 3. Kazdy komputer ma teraz swoj unikatowy adres IP w sieci Hamachi. Rutery, lokalne ip, firewalle, dynamicznie przydzielane IP nie mają tu żadnego wpływu na ich połączenie - dlatego ten program jest taki fajny Nie są potrzebne zadne rzeczy w stylu dyndns czy no-ip. 4. Załóżmy że serwer ma w sieci Hamachi adres 5.28.100.248 - odpalamy SQL Configuration Manager. Wybieramy SQL Server 2005 Network Protocols/Protocols for INSERTGT. Otwieramy TCP/IP i ustawiamy: General: Enabled - Yes Keep Alive 30000 (to mało istotna wartosc) Listen All - Yes NoDelay - No IP Adresses: IP1: Active - Yes Enabled - Yes IP Address - 5.28.100.248 TCP Dynamic Ports - 0 TCP Port - narazie zostawiamy puste. IPAll: TCP Dynamic Ports - 0 5. Zamykamy okienko i restartujemy SQL Server (INSERTGT). Po restarcie znowu wchodzimy w protokol TCP/IP do zakladki IP Addresses i sprawdzamy IPAll: TCP Dynamic Ports. Przydzielony dynamicznie port wpisujemy w miejsce TCP Port w IP1. Ten numer portu sie nam jeszcze przyda wiec warto go zapamietac badz spisac. 6. Start/Ustawienia/Połączenia sieciowe. Z menu górnego wybieramy ZAAWANSOWANE/Ustawienia zaawansowane. Zaznaczamy na liście hamachi i klikamy strzałką zeby było na samej górze jako pierwsze spośród wszystkich interfejsów. Klikamy OK. W tym momencie mamy gotowy serwer nasłuchujący na porcie który spisalismy o adresie IP 5.28.100.248 (oczywiscie przykladowy). Do serwera mozemy się podlaczyc teraz z dowolnego komputera ktory rowniez podalczy sie do tej samej sieci wirtualnej hamachi co serwer. A więc dalej jedziemy: 7. Na komputerach klienckich (czy są w sieci lokalnej czy to sa komputery w domu czy nawet w chinach - obojetnie, to nie ma wplywu) instalujemy Hamachi, logujemy sie do tej samej sieci którą stworzylismy dla serwera. 8. Otwieramy plik do edycji: C:\Documents and Settings\All Users\Dane aplikacji\InsERT\Sello\sello.xml <startup> <sql_server>5.28.100.248,PORT\INSERTGT</sql_server> <auth_mode>MIXED</auth_mode> <sql_login encrypted="0">sa</sql_login> <database>NAZWA_BAZY_DANYCH</database> <login encrypted="0">OPCJONALNIE_LOGIN\HASŁO</login> </startup> Po przecinku przy IP wpisujemy ten dynamiczny port na którym działa serwer SQL. 9. Odpalamy klienta. Cieszymy się z dostepu do Sello/Subiekta z kazdego miejsca na świecie. Kilka słów: 1. Transmisja w sieci Hamachi jest szyfrowana asymetrycznie 256 bitowym kluczem AES, takze przechwycone dane za pomocą snifferów są bezuzyteczne dla potencjalnego podsłuchiwacza. 2. Jesli komputery są w sieci lokalnej a do komunikacji uzywaja sieci Hamachi, predkość pozostaje taka sama - dodatkowym atutem jest szyfrowany przesył danych i dostepnosc kazdego lokalnego komputera z zewnatrz (świetna sprawa jeśli korzystamy czasami z Radmina albo UltraVNC) 3. Dla duzych baz danych Subiekta lub Sello predkość łącz ADSL jest zdecydowanie za niska, dlatego zamrażanie się aplikacji na kilka minut jest spowodowane długim czasem pobierania danych z bazy (po lokalu mamy predkość 100 Mbps w obie strony, na takiej np. neostradzie 1024 jedynie 1 Mbps downloadu i tylko 256 kbps uploadu). Przy uploadzie serwera rzędu 1 Mbps i więcej praca zaczyna nabierać sensu na odleglosc. W przeciwnym wypadku bardziej polecam uzywanie Radmina. 4. Podany sposob konfiguracji jest zarówno dla Subiekta GT jak i dla Sello. Jeśli są jakies wątpliwosci, słuzę pomocą Mam nadzieję że komuś się przyda

C:\Documents and Settings\All Users\Dane aplikacji\InsERT\Sello\sello.xml sekcja: <sql_server>NAZWA_SERWERA\INSERTGT</sql_server> <auth_mode>MIXED</auth_mode> <sql_login encrypted="0">sa</sql_login> <database>NAZWA_BAZY</database> <login encrypted="0">OPCJONALNIE_LOGIN\HASŁO</login>